统一访问顺序能切断死锁链，因死锁本质是循环等待，强制按固定顺序（如orders→order_items→customers）访问表可消除环路；索引缺失会导致全表扫描、锁范围扩大，显著增加死锁概率；事务中混入外部调用、大批次操作或冗余查询会延长持锁时间，加剧冲突。
SET LOCK_TIMEOUT 对死锁完全无效，它只管阻塞超时（报错 1204），而死锁是引擎在毫秒级检测后主动终止事务（报错 1205）——你根本等不到超时那一刻。
为什么统一表访问顺序能直接切断死锁链
死锁本质是循环等待：事务 A 持有 orders 锁、等 customers；事务 B 持有 customers 锁、等 orders。只要所有存储过程强制按同一物理顺序访问表，环就无法形成。
- 约定所有多表操作都按
orders → order_items → customers顺序写UPDATE或SELECT ... FOR UPDATE，哪怕某次只用到其中两张表 - 避免在存储过程中动态拼接表名或用
IF分支切换访问顺序——这会让执行路径不可预测 - 对跨模块调用的存储过程，可在开头加注释显式声明顺序，比如
-- LOCK ORDER: products → inventory → suppliers
索引缺失如何悄悄放大死锁概率
同一个 UPDATE 语句，没走索引时可能全表扫描+页锁升级，锁住成百上千行；走了覆盖索引则只锁目标行。更隐蔽的是 INCLUDE 列和 varchar(max) 字段会扩大锁范围。
- 检查执行计划中是否出现
Clustered Index Scan或Index Scan—— 这往往是全表/全索引扫描的信号 - WHERE 条件字段必须有索引，且类型匹配：比如
WHERE user_id = '123'中user_id是INT，但传入字符串就会隐式转换，导致索引失效 - 测试发现死锁频发时，先尝试删掉非必要
INCLUDE列，或把description varchar(max)改为varchar(500)，观察是否缓解
事务结构里最容易被忽略的三个“锁延长点”
事务越长，持锁时间越久，冲突窗口越大。很多死锁不是 SQL 写得错，而是事务边界划得松。
- 把
OPENQUERY、EXEC xp_cmdshell、HTTP 调用等外部依赖移出事务块——它们不释放锁，但可能卡住几秒甚至几十秒 - 避免
UPDATE后紧跟SELECT（尤其带聚合或关联），除非真需要读未提交数据；否则考虑拆成两个小事务 - 批量更新别一次性处理上万行，改用
TOP (200)分批 + 显式COMMIT，每批之间留出锁释放间隙
真正难的不是知道该怎么做，而是让所有开发人员在不同存储过程、不同业务线里坚持同一套锁顺序和索引规范——一旦有人绕过，死锁就可能在某个高并发瞬间重现。
