MKsql server / problems / slow-performance
“Slow” is usually the label people use before the estate has been narrowed to one real cause.
Start here if the complaints are real, the system feels broadly slow, and every fast explanation points in a different direction. The first useful move is to narrow the symptom into a smaller class of problem: blocking, waits, access paths, tempdb pressure, weak visibility, or a wider performance review.
Related
Start with the SQL Server waits guide when the signal is still broad, the SQL Server blocking guide if the system is really waiting on itself, the SQL Server indexing guide when access paths look weak, and SQL Server performance review when the diagnosis has already stalled and the business impact is real.
What it usually looks like
Common cause classes
Safe first checks
Why this page exists
Most teams do not search for waits, bad access paths, or tempdb pressure first. They search for “slow SQL Server” because that is the symptom they can defend. The system feels heavy, users are impatient, and previous quick fixes have not made the complaint go away.
That is why this page stays practical. Broad slowness can be blocking, indexing, tempdb stress, missing evidence, or simple platform mismatch. The first useful step is to split the symptom into a smaller class of problem and stop treating everything as one tuning bucket.
Best deeper pages
Start here when the signal is broad and the first job is to read workload pressure before naming the root cause.
Read this if broad slowness is really lock pressure, long transactions, or workload collisions being described too vaguely.
Start here if poor access paths, unstable plans, or large scans look more plausible than concurrency alone.
Open this if the workload slows under pressure, tempdb is growing badly, or operational setup is amplifying the pain.
Keep this in play if the bigger problem is weak evidence and the team cannot prove when or why slowness gets worse.
When outside help makes sense
This review makes sense once the estate is slow enough to affect work, the diagnosis keeps bouncing between theories, or the team needs a proper root-cause review instead of another round of tactical tuning.
Slowness is affecting users or internal teams often enough that it has become operationally expensive.
The diagnosis keeps bouncing between blocking, indexing, tempdb, infrastructure, and application behavior.
You need one review that ties symptoms back to workload evidence and leaves the team with a fix order.
Next step
If the slowness is already affecting work, use SQL Server performance review or go straight to contact with what feels slow, when it gets worse, and whether the team has already ruled anything out.
If the symptom still feels broad, start with the SQL Server waits guide.
If the slowness is starting to look more like lock contention than generic drag, move to SQL Server blocking problems.