Yeah, go look at the execution plan for each query. That will show you how the optimizer is using the indexes to satisfy these queries. While a query can logically...

I must have reversed it in my head as I've been typing these. Yeah, the estimate was for a lower value, but the higher value was returned. However, same rules....

Nah, according to the statistics, it's your data. The value passed matches the histogram for the 66,000 rows. Try changing the where clause and you're likely to see a change...

So, your stats are skewed. Some values are going to recommend 66,000 rows. Others are going to recommend 2. In this case, one possible solution, is to use a RECOMPILE...

You do have a lot of skew in the histogram. See how lots of values are less than 100, but a few are 66,000 & 81,000. If that's an accurate...

This object: [DATA_756].[dbo].[gbkmut].[IX_gbkmut_GLCard] [gl]

Had an estimated number of rows 2536.26 and an actual return of 66466. That's a pretty wide disparity. Especially since the table above it shows an estimated...

Piling on.

Nope. Bad approach.

Good approach: Assume you're not there. Provide as much detail as you can so a competent, but possibly ignorant, individual could get the job done. Go further....

Ken! Let's go man. More to do still. You're valued and needed. Please get well soon.

Hang on a second. Don't look at the estimated costs of the plans as a measure of performance. It absolutely is not. It's only a measure of the mathematics that...

A little testing later, the answer to my own question is answer is sp_statement_starting/completed and filter it by the Type to 'Prepared'. You can see the full query of prepared...

The rpc_starting event has a "statement" event field. That is the remote procedure call itself. It will include the procedure name, the parameters passed in, and the values passed to...

I'd talk 'em through it. They may want write access to be able to set up tests. Insert data sets or update them to prep for a particular test. Makes...

Right. So.

You're very focused on that spill. You actually have a couple. However, they're not the core of the issue. There's a lot to unpack here. If i had to...

Here's a formatted copy of the query for anyone who wants to look:

SELECT [Roles].[Role_ID] AS "legalRoleID",
       [Roles].[UserID] AS MainUserID,
  ...

As I said, why not JOIN to the original table? Embedding it as a function doesn't make sense.