Yeah, I'm not at all surprised that it installed. I just doubt it did anything during that install. It found higher versions or the same versions on all the stuff...

Way back in the day, Brad Macgeehee did a bunch of testing around reorganize and rebuild. What he found is that the majority of the time, reorganize almost didn't do...

This sums it up. You're taking a risk. It'll probably be OK. But it might not be.

In terms of function, yes. They're identical. In terms of supported hardware, etc., No, they're not identical. The developer version should function perfectly as a test system in non-production environments....

Look at the execution plan. It's possible that your data crossed a threshold that changed the row counts. Maybe it used to do an index seek and now it's doing...

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