SQL Server Performance Tuning

How We Boosted SQL Performance by 40x [Case Study]

Mark Varnas
No comments

Improvement after tuning





Reading from disk is the slowest operation SQL Server does.

Therefore, tuning for less disk “reads” is often the primary goal.


spPartsReceived stored procedure took 40,000-60,000 milliseconds to execute, causing app timeouts.

It was overdoing it with index scans, leading to excessive disk read operations.

Pre-tuning Metrics

Duration (ms)
Disk (number of reads)


  • Change: We’ve revised certain sections of the stored procedure.
  • Testing: We used the same test value for both old and new SP. The result set was identical, but the data row ordering was different.
  • Next steps: It is important to ensure that differences in data order will not lead to issues before implementing the change.

Before vs. After

We slashed number of disk reads from 687,157 to just 90.

No joke!

Below is a detailed breakdown.


  • Table ‘tblRcptheader’. Scan count 9, logical reads 28,911, physical reads 0
  • Table ‘tblRcptitem’. Scan count 9, logical reads 363,865, physical reads 0
  • Table ‘tblLineItems’. Scan count 9, logical reads 294,381, physical reads 0


  • Table ‘tblRcptheader’. Scan count 5, logical reads 27, physical reads 0
  • Table ‘tblRcptitem’. Scan count 1, logical reads 27, physical reads 0
  • Table ‘tblLineItems’. Scan count 5, logical reads 36, physical reads 0
Before After Improvement
Duration (ms)*40,000 <1,000~40x or 4,000%
Disk (number of reads)*687,15790~7,635x or 763,508%
*The numbers are an average of multiple T-SQL runs

Overall, we observed a staggering improvement, making the query duration 40 times less!

Duration (ms)

Before tuning
After tuning

Final thoughts

This case illustrates that tuning can’t always be perfected.

We aim to adjust the database code to avoid other changes.

Sometimes, even with an identical result set, rows may return in a different order, potentially disrupting the app.

It’s essential to collaborate with the client application team to confirm that a different row order won’t cause issues.

Many will say ‘it shouldn’t matter’ – but with big apps, there’s always a chance of finding unexpected problems. It might not be an issue, or it might.

The point is to be careful.

Article by
Mark Varnas
Founder | CEO | SQL Veteran
Hey, I'm Mark, one of the guys behind Red9. I make a living performance tuning SQL Servers and making them more stable. I channel my SQL into our SQL Managed Services, SQL Consulting and our internal database products.

Managed SQL Server services, consulting, and emergency support from expert DBAs to improve performance, predictability, and cost.

Get started with Red9 today.

Contact us

Discover More

Discover what clients are saying about Red9

Red9 has incredible expertise both in SQL migration and performance tuning.

The biggest benefit has been performance gains and tuning associated with migrating to AWS and a newer version of SQL Server with Always On clustering. Red9 was integral to this process. The deep knowledge of MSSQL and combined experience of Red9 have been a huge asset during a difficult migration. Red9 found inefficient indexes and performance bottlenecks that improved latency by over 400%.

Rich Staats 5 stars
Rich Staats
Cloud Engineer

Always willing to go an extra mile

Working with Red9 DBAs has been a pleasure. They are great team players and have an expert knowledge of SQL Server database administration. And are always willing to go the extra mile to get the project done.
5 stars
Evelyn A.
Sr. Database Administrator

Boosts server health and efficiency for enhanced customer satisfaction

Since adding Red9 to the reporting and DataWarehousing team, Red9 has done a good job coming up to speed on our environments and helping ensure we continue to meet our customer's needs. Red9 has taken ownership of our servers ensuring they remain healthy by monitoring and tuning inefficient queries.
5 stars
Andrew F.
Datawarehousing Manager
See more testimonials