SQL Server blocking vs. deadlocking — what's the difference?

Both involve sessions fighting over locks, and both can make queries feel stuck or slow — but they're fundamentally different problems with different fixes.

Blocking — a queue, not a bug

One session holds a lock; another session needs the same resource and simply waits its turn. This is normal, expected SQL Server behavior — every database has blocking constantly, for microseconds at a time. It only becomes a "problem" when the blocker holds the lock for an unusually long time, so everything queued behind it feels frozen or eventually times out.

Deadlock — a cycle, not a queue

Two (or more) sessions each hold something the other needs — a genuine circular dependency with no possible resolution on its own. SQL Server detects this automatically and kills one session (the "victim") to break the cycle, raising error 1205 immediately to that session.

How to tell which one you have

Diagnosing blocking

Check active blocking chains directly:

SELECT session_id, blocking_session_id, wait_type, wait_time, status
FROM sys.dm_exec_requests
WHERE blocking_session_id <> 0;

Follow the chain up to the session with blocking_session_id = 0— that's your actual head blocker. Fixing blocking usually means shortening that transaction, adding an index so it takes a narrower/shorter lock, or reconsidering isolation level (e.g. READ COMMITTED SNAPSHOT to avoid readers blocking writers).

Diagnosing a deadlock

You need the deadlock graph (Extended Events system_health session, or trace flag 1222) — see our guide to reading a deadlock graph. The fix is usually standardizing the order in which transactions touch tables, not just adding an index (though that often helps too).

Not sure which one you're looking at? Paste your slow query, your error, or a deadlock XML and get an instant, plain-English diagnosis.

Related