Query / index tuningPhysician-owned medical group, anonymized × red9CS-0248
A top clinical query, run 40,000 times a day, cut from 3 seconds to 1 millisecond
The problem. A physician-owned medical group with a heavy clinical query load had one statement carrying most of it. It ran about 40,000 times a day at roughly 3 seconds each, reading 228,621 pages per call. Multiplied across the day, that single query was burning tens of hours of SQL time and making clinicians wait on data they needed in front of a patient.
What we did. We captured the plan and the statistics, rewrote the query, and added a covering index matched to its filter and output columns, so the engine seeks a few rows instead of reading a quarter-million pages. We logged the numbers on both sides of the change in one sitting.
Red9 · Performance Impact
SQL capacity reclaimed
~31 hrs / day
Across ~40,000 daily runs of one query, on the same hardware.
Per-call duration
3,000x
About 3 seconds down to 1 millisecond per call.
Disk reads, per call
~57,000x less
228,621 down to 4 per call, IO off the box.
Duration
3 s → 1 ms
3,000x shorter
Disk reads
228,621 → 4
~57,000x less
Executions
~40,000 / day
unchanged
Top query
duration, per call
Where the numbers come from. Each multiple is the old value over the tuned one, so 3,000 ms divided by 1 ms lands at 3,000x. The ~31 hours reclaimed a day is roughly 40,000 runs at the ~2.999 seconds shaved off each. Every figure traces back to the group's own readings on both sides of the change.
The result. The clinical query now returns in about a millisecond and reads 4 pages instead of 228,621. Across roughly 40,000 calls a day, that hands the group back close to 31 hours of SQL processing daily, with no new hardware.
The technical detail
What the review found. The top query filtered a large clinical table with no covering index, so each of its ~40,000 daily calls scanned the table, about 228,621 reads a time.
What we changed (identifiers generalized for privacy):
-- Top clinical query scanned a large table: 228,621 reads, ~3 s per call.
CREATE NONCLUSTERED INDEX IX_clinical_lookup_covering
ON dbo.[clinical_records] (/* filter cols */) INCLUDE (/* output cols */);
-- query rewritten to seek the covering index; DROP INDEX rollback provided
The rewrite plus the covering index turned the scan into a seek: reads fell from 228,621 to 4, and the call dropped from about 3 seconds to 1 millisecond.