Improvement after tuning
DURATION
CPU
Most SQL Servers bottleneck on Disk, which is number of disk operations required to pull all data necessary to process the the query.
When tuning, the goal is often to get SQL Server to read less data from the disk.
Problem
We identified a long-running query that was throttling CPU usage to 70% and concurrently executing across 12 threads.
Here’s a glance at the pre-tuning metrics:
- Duration (query duration in milliseconds): 3,200,290
- Disk (number of read operations required to get all data needed): 942,222,862
The query execution time was 53 minutes or 3,200,290 ms while making almost 1 million disk read operations.
Solution
- After reviewing the query plan, we identified the culprit: a
NOT INoperation invoking aVIEW. - The fix was straightforward: switching the
NOT INoperation to aNOT EXISTSoperation. See below.
Here is how we modified the original query to fix the problem:
Note: Performance of NOT IN vs. NOT EXISTS – performance vise is often massive. This is one of those examples.
Before vs. After
Small changes, huge difference? Totally!
We slashed a query’s run time from 3,200,290 ms down to 92 ms. No joke!
Below is a comparison of the number of disk reads before vs after tuning:
Disk (number of read operations)
| Before | After | Improvement | |
|---|---|---|---|
| Duration (ms) | 3,200,290 | 92 | 34,785x or 3,478,576% |
| Disk (number of reads) | 942,222,862 | 30,312 | 31,084x or 3,108,415% |
Simple query rewrite reduced the duration of the stored procedure by a 34,785 times!
Duration – milliseconds
Final Thoughts
A simple tweak of swapping the
NOT INoperation for aNOT EXISTSoperation resulted in a 34,785x improvement.
In SQL performance tuning, it’s often crucial to understand how the SQL engine retrieves data.
