How We Boosted SQL Performance by 40x

Reading from disk is the slowest operation SQL Server does.

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

Problem

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.

Solution

• 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.

Before:

• 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

After:

• 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

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

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.