sql server死锁日志中deadlock-list是根节点，每个deadlock元素对应一次死锁事件，需重点分析process-list中的spid和inputbuf、resource-list中的objectname及锁模式（如s/x），并结合执行计划排查索引与事务设计问题。
怎么看 SQL Server 死锁日志里的 deadlock-list
SQL Server 默认不自动记录死锁，得先打开跟踪标志或配置扩展事件。最直接的是启用 trace flag 1222（全局）或用 system_health 扩展事件——后者更推荐，因为不重启服务、开销小。
查到的死锁图里，deadlock-list 是根节点，里面每个 deadlock 元素对应一次死锁事件。重点关注：process-list 里的 spid、inputbuf（实际执行的语句），以及 resource-list 中的 objectname 和 mode（比如 S 共享锁、X 排他锁）。
-
别只看谁“被选为牺牲者”：
deadlock victim只是被 Kill 的那个，真正的问题常出在另一个长期持锁却不提交的事务上 -
inputbuf有时只显示存储过程名，得去查sys.dm_exec_sql_text拿完整语句，尤其注意动态 SQL 拼接位置 - 如果
resource-list里频繁出现KEY或PAGE，说明索引粒度太粗，可能缺覆盖索引或 WHERE 条件没走索引
存储过程中哪些写法最容易引发死锁
不是所有事务都会死锁，但以下几种模式在存储过程中高频触发：
-
UPDATE和SELECT顺序不一致：比如 A 过程先更新表 X 再查表 Y，B 过程反过来，就容易形成循环等待 - 隐式事务没关：
SET IMPLICIT_TRANSACTIONS ON导致单条语句也开启事务，且不显式COMMIT就一直持锁 - 在循环里反复
UPDATE同一张表，且每次更新范围不同（如用TOP 100分页更新），导致锁升级成表级锁或锁范围重叠 - 调用外部接口（如
xp_cmdshell或链接服务器）时卡住，事务挂起，锁却没释放
检查时直接搜存储过程体里的 BEGIN TRAN、UPDATE、SELECT ... FOR UPDATE（如果用了），再对照死锁日志里的 inputbuf 定位具体行。
为什么加了索引反而死锁更多了
索引不是万能解药，加错地方会放大问题。常见情况：
- 新建的非聚集索引没包含查询中
SELECT的所有字段，导致回表（Key Lookup），锁住聚集索引键 + 非聚集索引页，锁数量翻倍 - WHERE 条件用了函数或类型转换（如
WHERE YEAR(CreateTime) = 2024），索引失效，全表扫描 + 行锁升级为页锁/表锁 - 复合索引列顺序和查询条件不匹配：比如建了
IX_A_B_C，但查询只用了B = ?，索引无法有效过滤，扫描范围大，锁争用高 - 没有维护统计信息，优化器选错执行计划，本该走索引却走了 Clustered Index Scan
验证方法：对死锁涉及的语句，用 SET STATISTICS XML ON 看执行计划，重点找 Index Scan、Key Lookup、Sort（可能触发 tempdb 锁）。
如何用最小改动降低死锁概率
线上不能大改？优先做这几件事：
- 给高频更新的表加上
READ_COMMITTED_SNAPSHOT ON（数据库级），把读操作从共享锁解放出来，大幅减少读-写冲突 - 在存储过程开头加
SET DEADLOCK_PRIORITY LOW，让该过程大概率成为牺牲者，避免拖垮关键业务流 - 把长事务拆成小事务：比如批量更新 10 万行，改成每 500 行
COMMIT一次，缩短锁持有时间 - 统一访问顺序：所有调用同一组表的存储过程，按固定顺序（如先
Orders，再OrderDetails）执行 DML
这些改动都不需要重写逻辑，但要注意：READ_COMMITTED_SNAPSHOT 会增加 tempdb 压力；DEADLOCK_PRIORITY 只影响选择，不解决根本锁竞争。
死锁不是孤立现象，它暴露的是事务边界模糊、索引设计脱节、执行路径不可控——日志里那几行 process 和 resource 节点，其实已经说清楚了谁在等什么、为什么等不到。
