SQL Server Blocking vs Deadlocks: What Is the Difference?

Blocking and deadlocks are both concurrency problems, but treating them as interchangeable leads to poor troubleshooting. Blocking means one session is waiting because another session holds an incompatible lock. A deadlock is a cycle in which sessions wait on each other in a way that cannot resolve without intervention.

Blocking is not automatically a problem

SQL Server uses locks to protect transactional consistency. If one transaction changes a row and has not yet committed, another transaction may need to wait. Short-lived blocking can therefore be completely normal.

Blocking becomes a problem when waits are longer than the application can tolerate, when a transaction remains open unexpectedly, or when a high-volume process blocks many other sessions.

What a blocking chain looks like

Imagine Session A updates a row and leaves the transaction open. Session B tries to update the same row and waits. Session C may then wait behind B or another resource held by A. The important session is often the head blocker: the session at the front of the chain that is not itself waiting on another session.

Deadlocks are different

A deadlock requires a cycle. Session A owns a resource Session B needs, while Session B owns a resource Session A needs. Neither can continue. SQL Server detects the cycle and chooses one transaction as the deadlock victim so the other can proceed.

The victim receives an error and its transaction is rolled back. The correct long-term fix is not simply retrying forever; it is understanding why the access pattern created the cycle.

A simple conceptual example

Session A locks Row 1 and then requests Row 2. Session B has already locked Row 2 and now requests Row 1. Both are waiting on the other. That is a deadlock.

How to investigate blocking

1. Identify the blocked request.
2. Identify the blocking session.
3. Trace the chain until you reach the head blocker.
4. Inspect the open transaction and query text.
5. Determine how long the transaction has been open.
6. Check whether the behaviour is expected for the workload.
7. Decide whether to wait, correct the application, or intervene operationally.

Useful evidence includes current requests, sessions, open transactions, wait types and the statement being executed. Avoid killing a blocker simply because its session ID is visible. Understand the transaction first. For a focused explanation, see slow SQL Server troubleshooting.

How to investigate deadlocks

Deadlocks are best investigated from a deadlock graph rather than from memory after the fact. SQL Server's system_health Extended Events session commonly captures deadlock information. A deadlock graph shows the processes, resources, locks and victim involved in the cycle.

Look for repeated patterns: inconsistent object access order, long transactions, missing indexes that increase lock duration, large scans, overly broad transaction scope or application code that touches the same resources in different sequences.

Why indexes can matter

An index does not 'fix locking' by itself, but a better access path can reduce the number of rows touched and the time locks are held. Conversely, a poorly chosen index can increase write overhead. The right decision comes from the actual execution plan and workload. Explore execution plans for more detail.

Isolation levels and row versioning

SQL Server isolation levels influence how readers and writers interact. Snapshot-based options can reduce some reader-writer blocking by using row versions, but they change concurrency semantics and tempdb usage. They should be selected intentionally, not enabled as a universal cure.

Common mistakes

• Assuming every lock is bad.
• Killing sessions before identifying the head blocker.
• Calling blocking a deadlock because users are waiting.
• Ignoring the deadlock graph and only retrying the transaction.
• Changing isolation level without understanding application consistency requirements.
• Adding indexes blindly without measuring the affected query.
• Leaving application transactions open while waiting for user input or external work.

A better mental model

A queue may clear naturally when the transaction in front finishes. A cycle cannot resolve by waiting; SQL Server must break it.

Prevention is often application plus database work

The durable fix may involve shortening transactions, accessing objects in a consistent order, improving indexes, reducing unnecessary work inside the transaction, changing application retry handling or revisiting isolation. DBAs and developers often need to solve concurrency problems together. The companion article on day-to-day DBA work develops this point.

Related training

SQL Server Performance Tuning & Troubleshooting includes blocking-chain analysis, controlled deadlock generation, Extended Events capture and deadlock-graph interpretation.

View the Performance Tuning course

Need help choosing the right course?

If you are not sure where to begin, contact Goalbi Academy and tell us your current experience level and what you want to learn.

Contact Goalbi Academy

References

Understand and Resolve SQL Server Blocking Problems - SQL Server

Deadlocks Guide - SQL Server

Monitor Performance by Using the Query Store - SQL Server