如何排查SQL存储过程死锁_分析死锁日志与索引优化

SQL Server死锁日志中deadlock-list是根节点，每个deadlock元素对应一次死锁事件，需重点分析process-list中的spid和inputbuf、resource-list中的objectname及锁模式（如S/X），并结合执行计划排查索引与事务设计问题。怎么看 SQL Server 死锁日志里的 deadlock-listSQL 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 定位具体行。为什么加了索引反而死锁更多了索引不是万能解药，加错地方会放大问题。常见情况： Zeemo AI 一款专业的视频字幕制作和视频处理工具