很多开发者误以为在存储过程开头加上 SET LOCK_TIMEOUT 5000 就能有效防止死锁，说实话，这完全是个误解。死锁与阻塞等待其实是两个截然不同的概念：SQL Server 引擎在死锁发生的 1–5 毫秒内便会迅速检测到循环等待，并主动终止其中一个事务（抛出 1205 错误），而 SET LOCK_TIMEOUT 仅控制语句在**被阻塞时最多等待多久才会抛出 1204 错误**——它根本撑不到死锁被触发的那一刻。换句话说，这个超时设置对死锁完全没有作用，真正能从根源上解决问题的是避免死锁产生的条件。
SET LOCK_TIMEOUT 并不能防止死锁，它对死锁完全无效。当死锁发生时，SQL Server 引擎会在 1–5 毫秒内检测到循环等待，并主动终止其中一个事务（报错 1205），而 SET LOCK_TIMEOUT 仅控制语句在**被阻塞时最多等待多久才抛出 1204 错误**——它根本等不到死锁触发的那一刻。真正需要做的是：避免死锁发生的条件，而不是试图用超时来“兜底”。
为什么 SET LOCK_TIMEOUT 在存储过程中加了也没用
常见错误写法：在存储过程开头加上 SET LOCK_TIMEOUT 5000，以为这样就能“防死锁”。实际效果却是：
- 死锁发生时，
LOCK_TIMEOUT尚未开始计时，事务就已经被引擎杀掉 - 它只影响单条语句（比如
UPDATE）在遇到其他事务锁住资源时的等待上限，完全不干预死锁判定逻辑 - 如果搭配重试逻辑，反而可能因为数据状态已变，引发新的死锁或业务逻辑错乱
SQL Server 存储过程里真正有效的死锁防控点
死锁的本质是多个事务以不同顺序申请同一组资源。防控核心就三条：锁序一致、持锁时间短、索引精准。
- 统一访问顺序：所有涉及多表操作的存储过程，强制按固定物理顺序访问表，例如始终
orders → order_items → customers，哪怕某次只更新其中两张表，UPDATE 语句也按照这个顺序来写 - 拆小事务：避免一次性 UPDATE 1000 行；改用
TOP (50)分批处理并显式COMMIT，从而减少锁持有窗口 - 删掉 HOLDLOCK/UPDLOCK 乱用：除非明确知道锁定范围（比如唯一索引查找），否则
SELECT ... WITH (UPDLOCK, HOLDLOCK)很容易锁住整页甚至整表 - 索引必须覆盖 WHERE 条件：通过执行计划确认是否走
Index Seek；避免使用varchar(max)或冗余INCLUDE列导致行过宽，从而触发锁升级
那超时设置到底该用在哪？
SET LOCK_TIMEOUT 的合理用途，仅限于防止“阻塞等待过久”，而不是防死锁。典型场景：
- 你有一条确定不会死锁、但可能被长事务卡住的
UPDATE，想让它最多等 3 秒就失败，避免应用线程挂死 - 必须在
START TRANSACTION后、执行语句前设置，否则不生效 - 值设为 0 表示立即失败（SQL Server 也支持），适合做轻量级预检
真正容易被忽略的点是：**死锁日志里出现的“牺牲品”往往不是最慢的语句，而是最先申请锁、又恰好形成环的那个事务**。优化不能只盯着执行时间，得看锁资源申请路径是否收敛、是否可预测。
