Index tuning with a code roadmapCommercial textile rental company, anonymized × red9CS-0317
Indexes took two availability procedures part of the way, and the report named the rest
The problem. A commercial textile rental company had two availability procedures dominating its rental management database. The first ran about 1,300 times a day and consumed roughly three hours of SQL time; the second ran about 1,500 times a day for another hour. Both were reading hundreds of thousands of pages per call.
What we did. We created indexes across the order-header, order-return, tracking, label, and item-master tables, then measured again. The gains were real but bounded, so the report went further: it specified replacing table variables with temp tables and restructuring a join that was multiplying rows, with the reasoning for each recommendation.
Red9 · Performance Impact
Daily time returned
~33 min / day
From the first procedure, across about 1,300 daily calls.
Second procedure reads
2.8x
359,300 down to 127,798 per call.
Code changes specified
2
Temp tables in place of table variables, and a join reworked to stop multiplying rows.
First procedure
8 s → 6 s
~1,300 calls/day
Second procedure
3 s → 2 s
~1,500 calls/day
Second reads
359,300 → 127,798
2.8x less
Second procedure
reads, per call
Where these numbers come from. The 33 minutes a day is the saving recorded in the client's own report for the first procedure at about 1,300 executions. The 2.8x is 359,300 reads over 127,798 on the second procedure. Both come from the client's own captures. We are quoting a partial win deliberately, because the remaining ground needed application changes that only the client's developers could make.
The result. Both procedures got measurably faster, roughly 33 minutes of daily SQL processing came back from the first one alone, and the client finished with a written, ordered account of what indexing could not reach and why. That is a more useful deliverable than a claim of a fix that never landed.
The technical detail
What the review found. Index gaps explained part of the cost. The rest sat in the procedure logic: table variables the optimizer could not estimate, and a join condition producing a Cartesian product that no index can undo.
What we changed (identifiers generalized for privacy):
-- Availability procs: ~1,300/day at 8 s and ~1,500/day at 3 s, reads in the hundreds of thousands.
CREATE NONCLUSTERED INDEX IX_red9_order_header_pickup
ON dbo.[order_header] (pickupDate, orderNumber) INCLUDE (statusCode);
-- further indexes added on order-return, tracking, label and item-master paths
-- recommended (client-side dev work): temp tables replacing table variables;
-- join predicate corrected to remove the Cartesian product
Splitting a result into what we fixed and what the application still owes is the honest way to report a workload like this one.