When “Optimized Locking” Slows You Down: A Real SQL Server 2025 Regression

SQL Server 2025 introduces a feature called Optimized Locking, designed to reduce blocking across read–modify workloads. In many environments it helps, but certain mixed workloads experience longer lock waits, stalled S → U → X transitions, and even occasional threadpool saturation.

The S → U → X upgrade problem

A common concurrency pattern:

• Session A takes an S lock (shared)
• Session B takes an S lock (shared)
• Session A attempts to upgrade to U/X (update, exclusive)
• Session B still holds its S lock (shared)

Optimized Locking changes when upgrades are attempted, and under load, this produces a wait chain that didn’t exist before.

How to detect you’re hitting it

SELECT 
    r.session_id,
    r.status,
    r.wait_type,
    r.wait_time,
    r.blocking_session_id,
    r.command,
    t.text AS sql_text
FROM sys.dm_exec_requests r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) t
WHERE r.wait_type IN ('LCK_M_U', 'LCK_M_X', 'LCK_M_S', 'LCK_M_IS');

SELECT 
    request_session_id,
    resource_type,
    resource_description,
    request_mode,
    request_status
FROM sys.dm_tran_locks
ORDER BY request_session_id;

Temporary workaround

MSFT released a trace flag to disable the new behavior while refinements are underway:

DBCC TRACEON(12324, -1);

Disable the trace flag to restore default behavior:

DBCC TRACEOFF(12324, -1);

When optimized locking works well

• Short, predictable OLTP writes
• Minimal row hotspots
• Workloads that don’t mix high-volume reads with updates

If your environment slowed down after upgrading to SQL Server 2025, this should be one of the first areas you evaluate. Mixed read-and-update hotspots are the most likely candidates for unexpected regressions under the new locking model.

More to read

• Optimized locking