好的，这是根据您提供的 SQL Server 死锁排查步骤整理的 Markdown 文档。
SQL Server 死锁排查指南
本文档介绍了两项关键的 T-SQL 查询，用于排查 Microsoft SQL Server 中的死锁问题。
1. 查询 system_health 会话中的历史死锁信息
system_health 是 SQL Server 默认启用的扩展事件 (Extended Events) 会话。它会自动捕获包括死锁 (xml_deadlock_report) 在内的多种系统事件，是排查近期发生的死锁的首选之地。
查询脚本
sql
复制代码
SELECT
XEventData.XEvent.value('(@timestamp)[1]', 'datetime') AS DeadlockDateTime,
XEventData.XEvent.query('(data/value/deadlock)[1]') AS DeadlockGraph
FROM
(SELECT CAST(target_data AS XML) AS TargetData
FROM sys.dm_xe_session_targets st
JOIN sys.dm_xe_sessions s ON s.address = st.event_session_address
WHERE s.name = 'system_health' AND st.target_name = 'ring_buffer') AS Data
CROSS APPLY
TargetData.nodes('//RingBufferTarget/event[@name="xml_deadlock_report"]') AS XEventData (XEvent)
ORDER BY
DeadlockDateTime 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) 后，可以使用以下查询来获取该会话的详细实时状态和资源使用情况。
查询脚本
sql
复制代码
SELECT
s.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 s
LEFT 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），但需谨慎评估其副作用。