要查出正在阻塞别人的事务ID，需查询sys.dm_exec_requests中blocking_session_id≠0的会话；若blocking_session_id=0但wait_type为LCK_M_*且状态为suspended，则可能处于死锁链中。
怎么查出正在阻塞别人的事务ID
死锁发生后，SQL Server不会自动告诉你哪个会话在“卡着”别人，得自己挖。核心是查 sys.dm_exec_requests 和 sys.dm_exec_sessions，重点关注 blocking_session_id 不为 0 的行。
实操建议：
- 运行
SELECT session_id, blocking_session_id, status, command, wait_type, last_wait_type FROM sys.dm_exec_requests WHERE blocking_session_id 0，快速定位“真凶”会话 - 如果
blocking_session_id = 0但状态是suspended且wait_type是LCK_M_*，说明它自己也在等锁，可能是死锁链一环 - 别只看
sp_who2—— 它不显示阻塞层级关系，容易漏掉嵌套阻塞 - 注意
session_id是正整数，而系统会话（如session_id ）不能 KILL，强行执行会报错 <code>Msg 6105, Level 14, State 1
KILL命令到底该杀谁：不是死锁报告里的SPID，而是阻塞源头
SQL Server的死锁图（deadlock graph）里会列出两个 victim 和 owner，但 KILL 的目标不是图里标红的那个“victim”，而是那个长期持有锁、没提交/回滚、还在阻塞别人的会话。
实操建议：
- 先用上一步查到的
blocking_session_id去关联sys.dm_exec_sessions，确认该会话的login_name、host_name和program_name，避免误杀运维或监控连接 -
KILL后事务会自动回滚，但回滚时间取决于已执行的修改量——大事务可能卡住几分钟，期间仍占用资源，status显示为rollback - 不要对
session_id = 1（system process）或任何session_id 执行 <code>KILL，会直接报错Cannot use KILL to kill your own process或权限拒绝
为什么KILL了还继续阻塞：事务没真正结束的三个信号
KILL 发出去不代表锁立刻释放。常见现象是查 sys.dm_exec_requests 还能看到该 session_id，status 是 rollback，或者干脆查不到但它锁还挂着——这说明事务回滚没完成，或锁被延迟释放。
实操建议：
- 检查
sys.dm_tran_locks：如果request_session_id还存在，且resource_type是OBJECT或PAGE，说明回滚中锁未清 - 观察
sys.dm_exec_sessions中对应会话的is_user_process是否为 0 —— 如果是，说明已被标记终止但内核线程还没退出 - 别急着再
KILL一次，重复执行同个session_id会报Msg 6107, Level 14, State 1: The specified session ID does not exist，因为命令已入队，只是没执行完 - 极端情况下（如回滚卡死），可能需要重启 SQL Server 实例，但这属于兜底操作，不是常规手段
如何防止下次又手动KILL：从应用层堵住根源
手动 KILL 是救火，不是方案。90% 的可复现死锁，根子在应用代码没控制好事务边界和访问顺序。
实操建议：
- 所有显式事务必须有超时设置：.NET 用
TransactionOptions.Timeout，Java 用@Transactional(timeout = ...)，避免无限期等待 - 统一 DML 操作顺序：比如固定先更新
Orders再更新OrderItems，避免 A 进程按 AB 顺序、B 进程按 BA 顺序加锁 - 避免在事务里做 HTTP 调用、文件读写、长时间计算 —— 这些会让事务 hold 锁时间不可控
- 把
SET LOCK_TIMEOUT 5000加到连接字符串或会话开头，让语句等锁超过 5 秒就直接报错，而不是变成阻塞源
死锁本身不可怕，可怕的是把它当成偶发故障忽略。真正难处理的，是那种每小时出现一次、每次锁住 3–4 个关键表、但日志里只留下一行 Deadlock encountered ... Deadlock victim 的场景——这时候光靠 KILL 解不了，得翻应用日志比对事务入口点。
