Who this is for
Teams dealing with recurring SQL Server performance problems in real work.
Environments where quick fixes have created theories but not a stable answer.
Managers who need a safer triage order before more production changes are made.
services / sql server / performance review
SQL Server performance review.
Use this when slowness, blocking, waits, or deadlocks are already costing time and nobody trusts the diagnosis yet.
This is for real production pain, recurring symptoms, and situations where partial fixes have changed the shape of the problem without removing it.
Common situations
Blocking keeps returning, but the root cause still feels unclear.
Wait data exists, but nobody is confident enough to act on it.
The workload feels random because timing, plans, or tempdb side effects keep changing the story.
Why call now
The timing signs that usually make this worth doing.
Users are already losing time and the team is spending too much effort debating theories.
The same symptom has returned after quick fixes, so the next change needs better evidence behind it.
The system is stable enough to investigate carefully, but painful enough that waiting will keep costing work.
What often shows up
The usual findings are rarely only one thing.
Victim queries getting blamed while the real blocker or transaction pattern stays untouched.
Waits, tempdb pressure, or missing-index hints that point in useful directions but are not conclusions by themselves.
Scheduled jobs, access paths, or application behavior that make the issue appear random from the outside.
Investigation
What gets checked first.
Current symptom shape: blocking, waits, deadlocks, broad slowness, or mixed signals.
Evidence that actually matches the complaint: waits, chains, plans, and workload timing.
Access paths, transaction scope, tempdb pressure, and other factors that keep manufacturing pain.
Output
What the review should settle.
A triage order that matches production behavior instead of a broad tuning wishlist.
Evidence-backed findings around waits, blocking, plans, indexing, and timing.
A clearer split between fixes that help now and bigger changes that need separate planning.
Capture notes so the team knows what to collect if the symptom returns.
Useful reading
These help when the symptom keeps coming back.
Blocking stabilization case study
An anonymized example of turning recurring blocking into evidence-backed triage.
Open case study
Sample performance output
Shows what should come back from a review: symptom shape, evidence, findings, and triage order.
Open sample
Weekly review checklist
Useful when the pain keeps returning and the team needs a steadier way to review repeat warnings and unfinished follow-up.
Open checklist
Not the right fit
Use something narrower or broader when this does not match.
A broad inherited-environment review where operational drift is the bigger issue.
A pure upgrade or migration planning engagement.
An outage so active that incident command matters more than structured review.
Next step
Request a performance review
Send the rough situation, version, urgency, and the main concern. It does not need to be polished.