SQL Server触发器无法捕获死锁牺牲品信息，因事务被选为牺牲品时会立即回滚，触发器根本不会执行；应通过扩展事件（如system_health）捕获死锁图XML，在<victim-list>中提取spid、inputbuf、clientapp等上下文。
死锁牺牲品信息无法直接从触发器中捕获
SQL Server 的 INSTEAD OF 或 AFTER 触发器本身**不会被死锁牺牲品执行到**——一旦事务被选为死锁牺牲品，SQL Server 会立即回滚其整个事务，包括尚未执行的触发器逻辑。所以试图在表级触发器里“记录当前被杀的语句”是无效的。
真正可行的路径是：利用 SQL Server 自带的死锁诊断机制，把死锁图（deadlock graph）持久化下来，再从中提取牺牲品的 executionStack、inputbuf、会话 ID、时间戳、数据库名等上下文。
启用 trace flag 1222 或系统健康会话（XEvent）捕获死锁图
trace flag 1222 会将死锁信息写入错误日志，但格式难解析、无结构化字段，且不包含完整的执行堆栈；更推荐使用扩展事件（Extended Events），尤其是内置的 system_health 会话（默认启用）。
检查是否已捕获死锁：
SELECT * FROM sys.dm_xe_session_targets xet JOIN sys.dm_xe_sessions xe ON (xe.address = xet.event_session_address) WHERE xe.name = 'system_health';
确认 system_health 中的 ring_buffer target 是否包含 xml_deadlock_report 事件。若需长期归档，建议创建自定义 XEvent 会话并写入 event_file：
- 目标设为
event_file（避免 ring buffer 被覆盖） - 事件过滤仅保留
xml_deadlock_report - 确保服务器有足够磁盘空间和读写权限
从 deadlock graph XML 中提取牺牲品上下文
死锁图 XML 中的 <victim-list> 节点明确标识了牺牲品，其 id 属性对应 <process> 节点中的 id。关键字段包括：
-
process[@id='...']/@spid→ 实际会话 ID（可能为 -1，表示内部任务） -
process[@id='...']/executionStack/frame/@procname→ 存储过程名（或adhoc/unknown） -
process[@id='...']/inputbuf→ 触发死锁的实际语句文本（注意：可能被截断） -
process[@id='...']/@clientapp和@hostname→ 应用与客户端信息 -
deadlock/@timestamp→ 精确到毫秒的死锁发生时间
示例提取（T-SQL）：
SELECT
XEvent.value('(event/@timestamp)[1]', 'datetime') AS [TimeStamp],
XEvent.value('(event/data/value/deadlock/victim-list/victimProcess/@id)[1]', 'varchar(50)') AS victim_id,
XEvent.value('(event/data/value/deadlock/process-list/process[@id=sql:column("victim_id")]/@spid)[1]', 'int') AS spid,
XEvent.value('(event/data/value/deadlock/process-list/process[@id=sql:column("victim_id")]/inputbuf)[1]', 'nvarchar(max)') AS inputbuf,
XEvent.value('(event/data/value/deadlock/process-list/process[@id=sql:column("victim_id")]/@clientapp)[1]', 'nvarchar(200)') AS client_app
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 = 'deadlock_logger' AND st.target_name = 'event_file'
) AS Data
CROSS APPLY TargetData.nodes('RingBufferTarget/event') AS T(XEvent);不要依赖 sys.dm_exec_requests 或 sys.dm_tran_locks 实时抓取牺牲品
死锁发生后，牺牲品事务已被强制回滚，sys.dm_exec_requests 中对应 session_id 很快消失（通常 sys.dm_tran_locks 在回滚完成后也清空。试图轮询这些 DMV 捕获“正在被杀”的瞬间，成功率极低且引入额外负载。
真正稳定的做法只有一条：从死锁图 XML 出发，解析出完整上下文后，再插入自定义日志表（如 dbo.deadlock_log）。注意字段长度要足够：inputbuf 可能超 4000 字符，建议用 nvarchar(max)；XML 解析必须用 .value() 配合 sql:column() 关联 victim-id，否则无法准确定位牺牲品节点。
最易忽略的一点：死锁图里的 @spid 值不等于当前连接 ID，它反映的是死锁发生时刻的会话标识，可能已被复用。所以不能拿它去查 sys.dm_exec_sessions 的实时状态，只能当作关联线索存档。
