<p>SQL Server中拦截无条件DELETE须用FOR DELETE触发器配合RAISERROR(16,1)并RETURN，通过DBCC INPUTBUFFER解析语句判断是否缺失WHERE；归档脚本需以/ ARCHIVE /标记放行；TRUNCATE/DROP需数据库级DDL触发器防护；必须撤销用户直接DELETE权限并禁用触发器滥用风险。</p>
SQL Server里用BEFORE DELETE触发器拦截无条件DELETE
不能靠AFTER或INSTEAD OF，必须用FOR DELETE + RAISERROR组合，并在触发器开头就判断是否为无条件删除。SQL Server没有真正的BEFORE触发器，FOR DELETE是实际可用的“前置拦截点”，但必须配合显式错误抛出，否则事务照常提交。
常见错误现象：PRINT、SELECT或只写RETURN，这些都不会中断事务，DELETE仍会执行成功。
- 检查是否无WHERE子句：通过
DBCC INPUTBUFFER(@@SPID)读取原始语句，匹配DELETE\s+FROM\s+\[?表名\]?且后面没跟WHERE或AND - 避免查大表或调UDF：INPUTBUFFER结果存临时表再解析，不要在触发器里查
sys.dm_exec_sql_text（需额外权限且性能差） - 必须用
RAISERROR(..., 16, 1)并紧跟RETURN，级别16才能让客户端感知失败，级别10以下会被静默吞掉
如何识别“无条件DELETE”而不误杀合法归档脚本
硬拦所有DELETE会卡住定时归档任务，关键在于区分语句意图，而不是拦住所有人工操作。最轻量可靠的方式是约定注释标记，而非依赖PROGRAM_NAME()或HOST_NAME()——容器化后这些值不可控、易伪造。
- 归档脚本统一以
/* ARCHIVE */ DELETE FROM orders ...开头，触发器用CHARINDEX('/* ARCHIVE */', @sql) > 0放行 - 禁止用
current_user或SUSER_SNAME()做判断：连接池常用固定账号，无法区分具体操作人 - 不推荐查
sys.dm_exec_sessions获取登录时间或应用名：开销大、权限要求高、且可能被绕过（如用sqlcmd -Q直接执行）
TRUNCATE TABLE和DROP TABLE根本不会触发DML触发器
FOR DELETE触发器对TRUNCATE TABLE完全无效，因为TRUNCATE是DDL操作，不走DML路径，也不生成deleted表。同样，DROP TABLE也不会触发它。
- 防TRUNCATE必须建数据库级DDL触发器：
CREATE TRIGGER tr_prevent_truncate ON DATABASE FOR TRUNCATE_TABLE AS RAISERROR('TRUNCATE is disabled', 16, 1); ROLLBACK; - 防DROP需另建
FOR DROP_TABLE触发器，注意它作用于整个数据库，不是单表 - 这两类DDL触发器本身可被
DISABLE TRIGGER禁用，所以必须限制用户对目标表的ALTER权限，否则防护形同虚设
触发器失效的三个隐蔽原因
即使逻辑写对了，触发器也可能静默不运行，问题往往不在代码本身，而在部署和权限配置。
-
DISABLE TRIGGER tr_name ON table_name只需ALTER权限，无需EXECUTE；检查状态用SELECT name, is_disabled FROM sys.triggers WHERE parent_id = OBJECT_ID('table_name') - 触发器定义者账号若属
db_owner角色，该账号一旦泄露，攻击者可直接删触发器或禁用它 - 如果用户仍有对表的
DELETE权限，他可以绕过触发器——直接删数据，根本不去触发它；必须REVOKE DELETE ON table_name FROM [user]，只授EXECUTE给封装了安全逻辑的存储过程
真正起作用的防护不是“写一个触发器”，而是“让触发器不得不运行”。这意味着要收掉基表DML权限、禁用高危DDL、用注释而非环境变量做上下文判断——这些环节漏掉任何一环，RAISERROR就只是日志里一行没人看的输出。
