Index tuningReal-estate accounting software vendor, anonymized × red9CS-0297
A hot accounting lookup, running around 68,000 times a day, freed close to 11 hours of daily SQL time
The problem. An accounting software vendor for the real-estate industry had one reporting query wired to a busy product screen, firing about 68,000 times a day at roughly 580 ms a call and reading 518,566 pages off disk on every run. Totaled across the day, that single statement ate close to 11 hours of SQL time and left the screen behind it feeling slow for everyone who opened it.
What we did. We pulled the plan and the Query Store history, saw the filter had no index under it, and built a covering index matched to the columns the query filtered and returned. The engine dropped from scanning the whole table to seeking a few pages, and a DROP INDEX rollback was staged before anything went in.
Red9 · Performance Impact
Daily SQL time recovered
~11 hrs / day
From one query running about 68,000 times a day, on the same box.
Reads per run
518,566 → 5
A full table scan turned into a short index seek.
Per-run time
580 ms → 1 ms
The same statement once the covering index landed.
Duration
580 ms → 1 ms
580x shorter
Disk reads
518,566 → 5
~104,000x less
Executions
~68,000 / day
steady
Daily SQL time
on one query
~11 hrs freed
now about a minute
How the math works. The roughly 11 hours comes from about 68,000 runs a day at the ~579 ms shaved off each, which is close to 11 hours of processing handed back daily. Reads fell from 518,566 to 5, a drop near 104,000x. All of it traces to the client's own before-and-after captures.
The result. The query now touches 5 pages and returns in about a millisecond. Spread across roughly 68,000 calls a day, the vendor gets close to 11 hours of SQL processing back every day, and the accounting screen it sits behind feels quick again, with no change to the hardware.
The technical detail
What the review turned up. The review pinned it to the accounting table behind that query, which carried no index matching the filter, so all ~68,000 daily calls fell back to a full scan of roughly 518,566 reads apiece.
What we changed (identifiers generalized for privacy):
-- The reporting query scanned an accounting table: ~518,566 reads, ~580 ms, ~68,000 runs/day.
CREATE NONCLUSTERED INDEX IX_acct_report_covering
ON dbo.[account_txn] (/* filter cols */) INCLUDE (/* output cols */);
-- rollback: DROP INDEX script staged alongside
Once the covering index was in place the scan collapsed into a seek: reads dropped from 518,566 to 5 and each run fell from about 580 ms to a single millisecond, over the same ~68,000 executions a day.