OK. Have you compared the execution plans as I suggested? Yes, it could be a system or database setting. However, it could be that the query is simply getting resolved...

You can get some estimates on row counts from the statistics. There's also DMVs that will show estimates on the row counts. However, nothing will show if there's duplicate data...

Compare the execution plans. Capture a full set of wait statistics for the query. Use the information from those two sources to see what the primary differences are. Overall, 2016...

Billions of rows over years and no constraint. I'd put good money down that there are non-unique values.

Easiest way I know to validate this would be to do two queries....

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...