如何通过设置锁超时和优化事务来有效解决SQL存储过程中的死锁问题？

本文共计1176个文字，预计阅读时间需要5分钟。

在SQL Server中，存储过程中的死锁问题可以通过以下方法避免：

为什么 SET LOCK_TIMEOUT 对死锁无效

死锁不是“等太久”，而是数据库引擎检测到循环等待后主动终止其中一个事务（报错 1205）；SET LOCK_TIMEOUT 只影响单个语句在遇到阻塞时最多等多久才抛出 1204 类超时错误，它根本等不到死锁发生那一刻——死锁监视器通常在几毫秒内就介入并杀掉牺牲品了。

常见误用场景：

• 在存储过程开头写 SET LOCK_TIMEOUT 5000，以为能“防止死锁”，实际运行中仍频繁收到 Deadlock encountered
• 把 LOCK_TIMEOUT 和事务重试逻辑混在一起，结果重试时因资源状态已变，反而加剧竞争
• 在高并发更新同一张表的多个字段时依赖它兜底，但真正卡住的是锁升级（如从行锁升页锁），超时设置毫无意义

真正起效的事务结构改造点

死锁本质是资源申请顺序不一致。两个存储过程若都按“先改订单、再改客户”执行，就不会成环；一旦一个按此顺序，另一个反着来，就极易触发死锁图里典型的“T1→T2→T1”闭环。