SQL Server死锁排查实战指南
好的，这是根据您提供的 SQL Server 死锁排查步骤整理的 Markdown 文档。
SQL Server 死锁排查指南
本文档介绍了两项关键的 T-SQL 查询，用于排查 Microsoft SQL Server 中的死锁问题。
1. 查询 system_health 会话中的历史死锁信息
system_health 是 SQL Server 默认启用的扩展事件 (Extended Events) 会话。它会自动捕获包括死锁 (xml_deadlock_report) 在内的多种系统事件，是排查近期发生的死锁的首选之地。
查询脚本
SELECTXEventData.XEvent.value('(@timestamp)[1]', 'datetime') AS DeadlockDateTime,XEventData.XEvent.query('(data/value/deadlock)[1]') AS DeadlockGraph
FROM(SELECT CAST(target_data AS XML) AS TargetDataFROM sys.dm_xe_session_targets stJOIN sys.dm_xe_sessions s ON s.address = st.event_session_addressWHERE s.name = 'system_health' AND st.target_name = 'ring_buffer') AS DataCROSS APPLYTargetData.nodes('//RingBufferTarget/event[@name="xml_deadlock_report"]') AS XEventData (XEvent)
ORDER BYDeadlockDateTime DESC;
结果集说明
| 列名 | 数据类型 | 说明 |
|---|---|---|
DeadlockDateTime | datetime | 死锁事件发生的准确日期和时间。 |
DeadlockGraph | xml | 死锁图，以 XML 格式描述死锁的完整信息。这是分析死锁的最关键信息。 |
如何分析死锁图 (DeadlockGraph)
- 在 SSMS (SQL Server Management Studio) 中执行上述查询。
- 点击结果集中
DeadlockGraph列的 XML 链接。 - SSMS 会在一个新的窗口中以图形化的方式展示死锁关系图，非常直观。
- 椭圆：表示参与死锁的进程（SPID）。
- 矩形：表示被争抢的资源（如键、页、表、行）。
- 箭头：表示进程对资源的请求和等待关系。
- 在图形化界面中，可以清楚地看到：
- 哪些两个（或多个）会话被卷入死锁。
- 它们各自持有(
owner)什么资源，又在等待(waiter)什么资源。 - 它们当时正在执行的 T-SQL 语句（
inputbuf）。
2. 查询特定会话 (SPID) 的详细信息
当从死锁图或其它途径（如监控、错误日志）获知一个具体的会话 ID (SPID) 后，可以使用以下查询来获取该会话的详细实时状态和资源使用情况。
查询脚本
SELECTs.session_id,s.login_name,s.host_name,s.program_name,s.status AS session_status,s.login_time,s.last_request_start_time,s.last_request_end_time,s.reads,s.writes,s.logical_reads,s.cpu_time,s.memory_usage,DB_NAME(s.database_id) AS database_name,r.status AS request_status,r.command,r.start_time,r.wait_type,r.wait_time,r.wait_resource,r.blocking_session_id, -- **关键：阻塞此会话的SPID**r.cpu_time AS request_cpu_time,r.total_elapsed_time,r.reads AS request_reads,r.writes AS request_writes,r.logical_reads AS request_logical_reads
FROM sys.dm_exec_sessions sLEFT JOIN sys.dm_exec_requests r ON s.session_id = r.session_id
WHERE s.session_id = 219; -- **替换为你需要关注的 SPID**
关键字段说明 (用于死锁/阻塞分析)
| 字段 | 来源 | 说明 |
|---|---|---|
session_id | s | 会话 ID (SPID)。 |
login_name / host_name / program_name | s | 帮助定位问题来源：哪个用户、从哪台机器、通过什么程序连接的。 |
status | s | 会话状态（如 running, sleeping）。 |
command | r | 当前正在执行的命令类型（如 SELECT, UPDATE, INSERT）。 |
wait_type / wait_time | r | 如果会话被阻塞，这里会显示它正在等待的资源类型（如 LCK_M_X）和已等待时间（毫秒）。NULL 表示未被阻塞。 |
wait_resource | r | 会话正在等待的具体资源（如 KEY: 5:72057594048872448 (xxxxxxxx)）。 |
blocking_session_id | r | 至关重要！表示是哪个 SPID 阻塞了当前会话。如果 > 0，则说明此会话正被另一个会话阻塞。这是排查阻塞链的核心字段。 |
last_request_start_time / last_request_end_time | s | 会话最后一次请求的开始和结束时间。 |
总结与排查步骤建议
- 发现死锁：通过应用程序错误日志、SQL Server 错误日志或监控工具发现死锁错误（错误号 1205）。
- 获取死锁图：使用第一个查询从
system_health会话中提取最近的死锁图。 - 分析死锁图：在 SSMS 中图形化查看死锁图，确定涉及的主要会话 (
SPID) 和争抢的资源。 - 调查会话详情：将图形中发现的
SPID代入第二个查询，了解这些会话的详细信息（谁发起的、从哪里来、在做什么操作），特别是blocking_session_id字段可以帮助确认阻塞关系。 - 解决问题：根据分析结果，通常的解决方案包括：
- 优化查询/索引：确保事务尽可能短小，为经常查询的字段添加索引，避免表扫描。
- 调整事务隔离级别：在必要时使用更低的隔离级别（如
READ COMMITTED）。 - 调整访问顺序：在应用层代码中，确保对不同资源的访问顺序在所有事务中都保持一致。
- 使用提示：在极少数情况下，考虑使用锁提示（如
NOLOCK,UPDLOCK,ROWLOCK），但需谨慎评估其副作用。