Query / indexed-view tuningNationwide multi-site services operator, anonymized × red9CS-0488
One indexed view sped up a whole set of stored procedures across a nationwide branch network
The problem. A nationwide multi-site services operator leaned on a cluster of stored procedures that all chewed the same expensive aggregation. The heaviest of them, a status-reporting procedure, ran near 3,200 ms a call and pushed roughly 1,100,000 rows through every execution, so the reports users needed most were the ones that crawled.
What we did. Rather than patch each procedure on its own, we built a single indexed view that pre-computed the shared aggregation, then pointed the procedures at it. One structure carried the load for the whole family. We recorded the readings on both sides of the change in one sitting.
Red9 · Performance Impact
Worst procedure, faster
8x
~3,200 ms down to ~400 ms per call.
Rows per execution
~7x
About 1,100,000 down to about 150,000.
One indexed view
every caller faster
A single structure lifted a whole family of stored procedures at once.
Duration
~3,200 ms → ~400 ms
8x shorter
Rows read
~1,100,000 → ~150,000
~7x less
Worst procedure
duration, per call
Where the figures come from. The 8x is the heaviest procedure's old duration over its tuned duration, roughly 3,200 ms against 400 ms. The ~7x is the drop in rows the same procedure had to read, near 1,100,000 down to 150,000. Both are the operator's own measurements on either side of the change.
The result. The heaviest procedure returns in about 400 ms instead of 3,200, and it reads roughly 150,000 rows in place of 1,100,000. Because the indexed view backs several procedures, the rest of the family got quicker off the same piece of work.
The technical detail
What the review turned up. A group of stored procedures each recomputed the same heavy aggregation from base tables, so the busiest one read about 1,100,000 rows and ran near 3,200 ms per call.
What we changed (identifiers generalized for privacy):
-- Pre-computed the shared aggregation once in an indexed view;
-- the family of procedures reads the view instead of the base tables.
CREATE VIEW dbo.vw_status_rollup WITH SCHEMABINDING AS
SELECT /* grouped keys */, COUNT_BIG(*) AS rc
FROM dbo.[job_records] GROUP BY /* keys */;
CREATE UNIQUE CLUSTERED INDEX IX_vw_status_rollup ON dbo.vw_status_rollup (/* keys */);
With the aggregation materialized in the view, the worst procedure fell from about 3,200 ms to 400 ms and from roughly 1,100,000 rows to 150,000, and its siblings rode the same gain.