Locking is the normal internal mechanism SQL Server uses to protect data consistency when many sessions run at once. Blocking happens when one session holds a lock another session needs, forcing it to wait.
Locking is healthy and constant; brief blocking is normal too. The problem is prolonged blocking — and the most effective cure is usually making the offending query faster so it releases its locks sooner.
"Locking," "blocking," and "deadlocking" are often used interchangeably and shouldn't be. Getting the distinction right is the difference between chasing a non-problem and fixing a real one.
Locking vs. blocking vs. deadlocking
- Locking (normal)
- SQL Server takes locks to let multiple users work concurrently without corrupting data. A process taking a lock that no one else needs is just locking — nothing is wrong.
- Blocking (waiting)
- One session holds a lock; another needs a conflicting lock on the same resource and must wait. Brief blocking happens constantly with no noticeable impact; prolonged blocking degrades performance.
- Deadlocking (mutual)
- Two sessions each hold a lock the other needs, so neither can proceed. SQL Server detects this and kills one as the "deadlock victim" to break the cycle.
Why blocking happens
Blocking is a natural consequence of locking — it only becomes a problem when locks are held longer than necessary. The usual causes:
- Long-running transactions that hold locks for their entire duration.
- Inefficient queries that scan and lock far more data than they need.
- Lock escalation, where many row or page locks are escalated to a table lock on a large operation.
Finding the head blocker
The diagnostic approach is to find the head blocker — the session at the root of the wait chain that everyone else is waiting on — then determine what it is doing and why it is holding locks for so long. Once you know which query is the culprit, you can address the cause.
How to reduce blocking
Per Microsoft's guidance, the levers are about holding fewer locks for less time:
- Optimize the query and indexes so it finishes faster and touches fewer rows — the single most effective lever.
- Keep transactions short to release locks quickly.
- Break large batch operations into smaller ones to reduce the lock footprint and avoid escalation.
- Choose an appropriate isolation level for the workload.
This is the optimization connection: a procedure that runs in 0.6 ms instead of 60 ms holds its locks for a hundredth of the time. Tuning the query is often the most durable way to cut blocking — and replacing a cursor with set-based logic is a classic blocking fix, since cursors hold locks across many round-trips.
Where optimization helps
Blocking is frequently a performance problem wearing a concurrency costume: the lock is held too long because the query is too slow. SprocOptimizer does not manage locks or isolation levels directly, but by making a stored procedure faster — fewer reads, a better plan, set-based instead of row-by-row — it shortens how long that procedure holds its locks, which reduces the blocking it causes. As always, the rewrite is validated for identical results before promotion.
Frequently asked questions
Locking is the internal mechanism SQL Server uses to protect data consistency while multiple sessions run at the same time. Blocking happens when one session holds a lock and another session needs a conflicting lock on the same resource, so the second session must wait. Locking is normal and constant; blocking is the waiting it sometimes causes.
No. Locking is normal, healthy behavior — it is how SQL Server lets many users work concurrently without corrupting data. If a process takes a lock and nothing else needs it, that is just locking and nothing is wrong. The problem is prolonged blocking, where sessions wait a long time for locks to be released.
Blocking is caused by conflicting locks held longer than necessary — typically by long-running transactions, inefficient queries that scan and lock more data than needed, or lock escalation on large operations. The diagnostic approach is to find the head blocker (the session at the root of the wait chain) and determine why it is holding locks for so long.
Reduce how long and how much data sessions lock: optimize queries and add appropriate indexes so they finish faster and touch fewer rows, keep transactions short to release locks quickly, break large batch operations into smaller ones to avoid lock escalation, and choose an appropriate isolation level. Faster queries are one of the most effective ways to reduce blocking because they hold their locks for less time.
Primary sources & further reading
- Microsoft Learn — Understand and resolve blocking problems.
- Brent Ozar — What's the difference between locking, blocking, and deadlocking?
- Redgate Simple Talk — The DBA as Detective: Troubleshooting Locking and Blocking.
Cut blocking by cutting query time
SprocOptimizer makes procedures faster and validates the result — shortening how long they hold locks — on-premises, with no row-level data leaving your network.
Request a Demo Read the Optimization Guide