sql server 本身不提供“自动杀死长连接”的内置机制，但可通过组合 sys.dm_exec_sessions、sys.dm_exec_requests 和 sys.dm_tran_locks 视图，配合定时作业与存储过程，实现对长时间空闲连接或死锁会话（blocking_session_id = -2）的识别与终止；核心依据是阻塞关系而非连接时长，真正该 kill 的是阻塞源头（blocking_session_id > 0）或已标记的死锁牺牲品。
直接上结论：SQL Server 本身不提供“自动杀死长连接”的内置机制，但可以通过组合 sys.dm_exec_sessions、sys.dm_exec_requests 和 sys.dm_tran_locks 视图，配合定时作业 + 存储过程，实现对**长时间空闲连接（Idle）** 或 **已确认死锁的会话（blocking_session_id = -2）** 的识别与终止。关键不是“长连接”本身有问题，而是它可能持有锁却不释放——真正要杀的是**阻塞源头**或**死锁牺牲品**。
怎么查出真正该 kill 的会话（不是看 login_time，而是看 blocking_session_id）
很多人误以为“连接时间久=该杀”，其实错的。SQL Server 中判断是否该干预，核心依据是等待链和死锁标识：
-
blocking_session_id = -2表示该会话是 SQL Server 自动选中的死锁牺牲品（已被标记，但尚未被 KILL），这是最明确的 kill 信号 -
blocking_session_id > 0表示该会话正在阻塞别人，且自身没有被更高层阻塞 —— 这才是真正的“阻塞源头”，优先 kill 它 -
status = 'sleeping'且last_request_end_time距今超过阈值（比如 30 分钟），才说明是空闲连接；但仅 sleep 不等于有害，除非它还持有锁（需关联sys.dm_tran_locks验证） - 别只查
sysprocesses（已弃用），必须用sys.dm_exec_sessions+sys.dm_exec_requests联查，否则拿不到准确 blocking 关系
存储过程里怎么安全地 kill，避免误杀或权限失败
直接拼接 KILL @spid 很危险，必须加三层防护：
- 先查
sys.dm_exec_sessions确认is_user_process = 1，排除系统会话（如 LAZY WRITER、CHECKPOINT） - 再查
sys.dm_exec_requests确认该会话当前没有活跃请求（session_id不在结果集中），或虽有请求但blocking_session_id = -2 - 执行
KILL前加TRY...CATCH，捕获Msg 1205（死锁牺牲品已结束）、Msg 6103（会话不存在）等常见错误，避免存储过程中断 - 不要用
EXEC('KILL '+@spid)，改用EXEC sys.sp_executesql N'KILL @p1', N'@p1 int', @p1 = @spid，防止注入和类型转换问题
为什么定时作业比触发器更靠谱
SQL Server 没有“死锁发生时触发”的原生事件，traceflag 1222 或 Extended Events 只能记录死锁图，不能直接触发 KILL。所以实际落地只能靠轮询：
- 用 SQL Server Agent 创建作业，每 30 秒跑一次存储过程（太频繁会增加系统负担，太慢则业务已卡住）
- 作业步骤用 T-SQL，不是 PowerShell 或 CmdExec，避免权限跨上下文问题
- 作业运行账户必须有
VIEW SERVER STATE和ALTER ANY DATABASE（或至少目标 DB 的db_owner），否则查不到会话或 KILL 权限不足 - 千万别用
sp_who_lock这类老式存储过程（依赖已废弃的sysprocesses），它在 SQL Server 2016+ 上可能漏掉新会话或返回错误 blocking 关系
最容易被忽略的兼容性坑：SQL Server 版本差异
同一个查询，在不同版本行为可能完全不同：
-
sys.dm_exec_sessions.last_request_end_time在 SQL Server 2005+ 才可用，2000 必须用login_time+ 估算，极不可靠 -
blocking_session_id = -2是 SQL Server 2005 引入的死锁标识，2000 只能靠sysprocesses.blocked = 0 AND spid IN (SELECT blocked FROM sysprocesses)推断，逻辑复杂且易误判 -
sys.dm_tran_locks的resource_description字段在 2012+ 才支持解析页锁/键锁细节，旧版只能看到模糊资源名 - 如果你还在用 SQL Server 2000，别折腾存储过程自动 kill —— 直接升级，或者用 Windows 计划任务调
osql -E -Q "exec sp_killlock 1"更现实
真正难的不是写 kill 逻辑，而是区分“该杀的阻塞源头”和“不该动的长事务”。一个未提交的银行转账事务跑了 5 分钟，和一个忘记 commit 的测试脚本挂了 2 小时，表现一样但处置方式相反。监控脚本里必须留人工干预开关（比如加参数 @dry_run = 1），上线前务必在非生产环境用真实阻塞场景压测验证。
