In real projects, performance issues donβt come with clear errors.
They appear as:
- Slow application
- Timeouts
- Random failures
In this blog, weβll walk through a real-world style incident and solve it step by step using Microsoft SQL Server.
1οΈβ£ The Problem
π Scenario
A live production system suddenly became slow:
- API response time: 200 ms β 15 seconds
- Users complaining
- CPU usage high
No code deployment was done recently.
2οΈβ£ Initial Investigation
First rule: Donβt panic. Gather data.
Check running queries:
SELECT *
FROM sys.dm_exec_requests
WHERE status = 'running';
Observation:
β One stored procedure consuming high CPU
β Running multiple times
3οΈβ£ Identify the Problem Query
Problem stored procedure:
EXEC dbo.GetUserOrders @UserId = 100;
4οΈβ£ Check Execution Plan
Enabled actual execution plan.
Findings:
β Table scan on Orders (10 million rows)
β High cost operator
β Missing index warning
5οΈβ£ Check Indexes
Query:
SELECT *
FROM Orders
WHERE UserId = @UserId;
Issue:
β No index on UserId
6οΈβ£ Immediate Fix
Created index:
CREATE INDEX IX_Orders_UserId
ON Orders(UserId);
7οΈβ£ Result After Fix
| Before | After |
|---|---|
| 15 sec | 120 ms |
Huge improvement π―
8οΈβ£ But Problem Came Back Againβ¦
After a few hours:
β Query slow again
β Same procedure
9οΈβ£ Deep Investigation
Checked execution plan again.
New Issue:
β Parameter sniffing
What Happened?
- First execution used small dataset β good plan
- Next execution used large dataset β bad plan reused
π Fix Parameter Sniffing
Solution 1: Use OPTION (RECOMPILE)
SELECT *
FROM Orders
WHERE UserId = @UserId
OPTION (RECOMPILE);
Solution 2: Use Local Variable
DECLARE @LocalUserId INT = @UserId;SELECT *
FROM Orders
WHERE UserId = @LocalUserId;
1οΈβ£1οΈβ£ Additional Findings
π Blocking Issue
EXEC sp_who2;
Found:
β Blocking caused by long transaction
Fix
β Reduced transaction time
β Optimized update query
1οΈβ£2οΈβ£ Final System State
After all fixes:
β Query execution stable
β Response time: ~100 ms
β CPU usage reduced
β No blocking
1οΈβ£3οΈβ£ Lessons Learned
β Always check execution plan first
β Indexing is critical
β Parameter sniffing is real
β Monitoring is essential
β Fix root cause, not symptoms
1οΈβ£4οΈβ£ Production Debugging Checklist
When facing performance issue:
β Identify slow query
β Check execution plan
β Verify indexes
β Check statistics
β Look for blocking
β Analyze parameter sniffing
β Apply fix and monitor
1οΈβ£5οΈβ£ Pro Tips
β Never change multiple things at once
β Always test fixes
β Monitor after deployment
β Document root cause
βοΈ Conclusion
Real-world SQL debugging is about:
β Systematic approach
β Understanding internals
β Using the right tools
This case study shows how small issues like:
- Missing index
- Parameter sniffing
can cause major production failures.
π₯ This blog is a gold-level content piece β perfect for interviews and real-world learning.
