How to Think Like the SQL Server Engine Part 3

We finished part 2 by adding a nonclustered index. Now, let's see all the ways that makes our query go faster. Then, we'll add more columns to our query so that the index isn't covering anymore, and we'll force SQL Server to make a tough decision: do lots of key lookups, or just scan the table? Then we'll learn how SQL Server uses statistics to make that decision.

[@dtovee]

Thanks, I'm happy that is isn't still live as I'm well over the 2 hours late benchmark!

[@chrislockhart4819]

I believe that "LastAccessDate BETWEEN '2018-08-27' AND '2018-08-28'" is not going to get exactly the same results in all cases as "CAST(LastAccessDate AS DATE) = '2018-08-27'" because the BETWEEN will also include any rows that are exactly at midnight 2018-08-28 which would be excluded from CAST AS Date method. So you would want to use "LastAccessDate >= '2018-08-27' AND LastAccessDate < '2018-08-28'"

[@marcosoliveira8731]

14:47 the best joke

[@klausnordmeyer]

2:09 I can undertand not using IX_ as an index name prefix. But not including the table name seems a bit dicey, since that almost guarantees that names for indexes created on the same column(s) in different tables will collide.
SQL server doesn't appear to allow use of the same name for indexes created on different tables.

[@TheBrentOzar]

Pro tip: before you say something like that, try it on your own server. That way, you'll learn that you're wrong privately - that SQL Server supports the same index name on different tables - instead of learning it publicly, here in the CZcams comments.

[@thomasegan9919]

Sorry but less drama and of topic stiff would be good. Peoples time is shorr, i am a long time follower of yours