How We Made T-SQL Queries Run 11 Times Faster

Reading from disk is the slowest operation SQL Server does.

Therefore, tuning for less disk “reads” is often the main target.

Problem

A slow stored procedure heavily affected the SQL Server performance.

Solution

Here is how we fixed it:

• To improve the stored procedure performance, we created four VIEWs.
• Also, we made changes to the stored procedure code, removing a few tables from the EXISTS operator that were part of the LEFT JOIN.

Before vs. After

The improvement was huge: the total number of disk reads dropped from 72,872,635 to just 881,626!

That’s 83x!

Below you will see a comparison of SQL procedure performance before and after tuning.

Overall, we observed a staggering improvement, making the query execution 11 times faster!

Final thoughts

The most common bottleneck for SQL Servers is disk access (or disk "reads").

It's neither the CPU nor the RAM, which are usually the first suspects for most customers.

And that makes much sense. Here is why:

• Inefficient queries scan (or read) much data.
• Data read in is stored in RAM. As more data is read in, “older” data is pushed out from RAM.
• If there isn’t enough RAM to keep ALL data in memory (which is often not possible), SQL Server has to read from disk – and that is the slowest operation SQL Server can do.
• When the query can be tuned to read 10 rows vs. 10 million – less CPU and RAM automatically are necessary.

Disk resources are the cause of 95% of SQL Server bottlenecks, so reducing the disk reads is usually the primary objective.

For the end-user, nothing is more crucial than the speed (or duration) of the query, in every case.

Tuning to reduce CPU/RAM resources is helpful too.

When queries are tuned to need less CPU & RAM, it means that the same server now has more capacity.