People do this all the time. It's relatively standard. The only real issue with it is ensuring that your network doesn't become the bottleneck instead of I/O. That's just about...

Yep. What John says. The cumulative update is just that, an accumulation of updates, security or not, up to that point. Can you add a newer security update created after...

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