Is it true that creating the index is quicker than running the query you needed it for? Let me show you the answer
Tonight, Ladies and Gentlemen, we have one of the most expected fights in SQL Server!! Yeeeeeah!! Booooohhhh!!! (People cheering and booing)
Hm, now seriously, I just read a comment in a blog post called Indexes Helping Indexes and one user wondered why creating an index is always faster than running the same SELECT statement.
My immediate thought was that cannot be true, but I need to prove it!
For these cases where I need a slightly longer running query, I use the big version of AdventureWorks, you can find it in Adam Machanic’s blog.
I will create one index on [dbo].[bigTransactionHistory] and then create an index using the same columns and sorting
First things first, here is the table, about 31M rows.
To be fair to both opponents, I will do a little trick to get all data into cache, so both will benefit from not having to go disk to read it. (You’ll see it later)
Now I can create the index
You can see that all reads are logical, no physical, no read aheads, hence no disk is involved. About 13 seconds
Now let’s run the query again and see what happens
BOOM! My system is not so bad… i7 16GB RAM, SSD … true that I keep opening new tabs everywhere, but… It really did take longer, 13 secs for CREATE INDEX vs Crashing after 23 secs.
He might be right… a query takes longer than index creation. Let’s try a little trick before giving up
And run the query again in a new window (IMPORTANT!!)
That’s more like it! Obviously there are no results as we requested, not even STATISTICS, but we can see that numbers (10 vs 13 secs) are pretty similar (~ish) if not lower than CREATE INDEX as it actually does less.
The reason is very simple, SSMS is pretty SLOOOOOOW and processes rows 1 by 1 so it consumes a lot time before it finishes displaying them in the default grid. Since CREATE INDEX happens internally, we have the illusion that is faster, but it’s only faster displaying the results.
This trick is very useful together with stopping «Display Actual Execution Plan» (As Erik Darling points) to tune queries as probably SSMS will not be the final user application, so removing the time to display the results will give you a better idea of how long the query really takes.
Hope you enjoyed reading and feel free to comment here or in the original post