SQL Server存储过程无法真正防KILL，但可通过sp_getapplock实现逻辑层自我保护，确保任务原子性：要么全执行完，要么完全不开始，避免脏数据。
SQL Server 存储过程中无法真正“防止被 KILL”，但能大幅降低被误杀或恶意终止的风险——关键不是锁住自己的 session_id，而是让 KILL 命令对你当前会话根本不起作用。
为什么 DENY ALTER ANY DATABASE 不等于“防 KILL”
很多人试过 DENY ALTER ANY DATABASE TO [user] 或类似语句，结果发现 KILL 依然成功。这是因为：KILL 权限不依赖数据库级角色，而由 sysadmin 或 ALTER ANY CONNECTION 显式授予；普通用户即使没这些权限，只要连接是用具有该权限的账号（比如 sa）建的，KILL 仍可执行。
更现实的问题是：你无法阻止 DBA 或系统管理员执行 KILL @spid，也不该试图阻止——那是运维权责范围。真正要防的是误操作、脚本错误、监控工具误判后的自动 Kill。
- 检查当前会话是否属于高权限登录：
SELECT login_name, is_sysadmin FROM sys.dm_exec_sessions WHERE session_id = @@SPID - 如果
is_sysadmin = 1，任何DENY都无效；此时唯一可控的是避免用 sa 连接跑长期存储过程 -
DENY ALTER ANY CONNECTION只对非 sysadmin 用户有效，且需在master数据库中执行
用 sp_getapplock 实现逻辑层“自我保护”
这不是阻止 KILL，而是让 Kill 后续业务逻辑失效——即：即使会话被干掉，也不会留下脏数据或半截任务。
典型场景是定时作业类存储过程（如每日结算），你希望它“要么全做完，要么完全不开始”。这时可在开头加应用锁：
DECLARE @result INT;
EXEC @result = sp_getapplock
@Resource = 'DailySettlementLock',
@LockMode = 'Exclusive',
@LockOwner = 'Session',
@LockTimeout = 5000;
IF @result < 0 BEGIN
RAISERROR('Another instance is running. Exiting.', 16, 1);
RETURN;
END
注意点：
- 锁名必须全局唯一且稳定，不能拼接时间戳或随机数，否则起不到互斥作用
-
@LockOwner = 'Session'表示锁随会话生命周期自动释放，哪怕被 KILL，锁也立刻消失，不会卡死 - 别在事务里调用
sp_getapplock后再开事务——锁持有时间应尽量短，只包核心判断段
让 KILL 失去业务意义：拆事务 + 提前校验
很多“怕被 Kill”的真实诉求，其实是怕 Kill 导致中间状态残留（比如更新了 A 表但没来得及更新 B 表）。与其防 Kill，不如让 Kill 发生时影响最小。
- 把长事务拆成多个小事务，每步完成后
COMMIT，并记录进度到状态表（如job_status中标记 'step1_done'） - 在存储过程开头查状态表，跳过已成功步骤，实现幂等重入 —— 即使被 Kill，重启后直接从断点继续
- 避免在事务中做耗时外部操作：
OPENQUERY、EXEC xp_cmdshell、HTTP 调用等一律移出事务块，否则 KILL 时可能卡在不可回滚状态 - 用
TRY...CATCH包裹关键段，确保异常时能清理临时表、释放资源，而不是留一堆未提交变更
最难的不是技术方案，而是所有开发人员都遵守同一套锁命名规范、事务边界划分和状态记录方式——一旦有人绕过 sp_getapplock 或把整个流程写进一个大事务，Kill 的风险就又回来了。
