SET LOCK_TIMEOUT 对死锁完全无效，它仅控制阻塞等待超时（报错1204），而死锁由SQL Server引擎毫秒级检测并主动终止事务（报错1205）；真正有效的是统一锁序、缩短持锁时间及优化索引覆盖。
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 表示立即失败（MySQL 8.0.19+ 支持，SQL Server 也支持），适合做轻量级预检
