But from that point forward, it has to examine every row that it finds. SQL Server is opening up the EndDate_StartDate index, and it’s turning to the first row where the EndDate >= GETDATE(), and then it starts reading. Not exactly: look at the Seek Predicates at the bottom of that tooltip. I can almost hear you screaming, “How is that possible?!? It says SEEK right on there, so we’re seeking to the rows we need, right?” They read 4.5M rows – half of the table – in order to produce a whopping 0 rows. Hover your mouse over either index seek, and check out the number of rows read: While this looks like a pair of lightweight index seeks, both of these queries did a heck of a lot of work. These seeks read a lot of data to produce 0 rows. It looks like a pair of simple index seeks, but they don’t perform worth a damn:
Now, when I run the query to check our active members again, there are a few tricky problems hidden in a plan that looks deceivingly simple.
0 kommentar(er)
