AFTER DELETE触发器不适合防误删，因其在数据已物理删除后才执行，无法回滚已丢失行；INSTEAD OF DELETE可拦截并控制删除逻辑，TRUNCATE和DROP则需DDL触发器或权限管控。
不能只靠一个触发器就防住所有误删——INSTEAD OF DELETE 能拦 DELETE，但 TRUNCATE 和 DROP 完全不触发它，且 AFTER 触发器删完才跑，根本来不及救。
为什么 AFTER DELETE 触发器不适合防误删
AFTER DELETE 触发器在数据已经从表中物理移除后才执行，deleted 表虽存在，但原始行已不可恢复（除非整个事务未提交）。此时再抛 RAISERROR 或 ROLLBACK，只会让客户端看到“报错”，而数据早已消失。
- 常见错误现象：触发器里写
IF (SELECT COUNT(*) FROM deleted) > 100 RAISERROR(...)，结果是“删了1000行再报错” - 它适合做审计日志或异步归档，不适合实时拦截
- 若业务逻辑依赖事务原子性，AFTER 触发器里的异常还可能干扰上层重试机制
INSTEAD OF DELETE 是唯一能真正阻止 DELETE 的方式
INSTEAD OF DELETE 不会自动执行原删除操作，而是完全替代它——你不在触发器里写 DELETE FROM ...，数据就一动不动。这是防误删的正确起点。
- 必须显式判断并决定是否放行：比如只允许删
status = 'archived'的记录 - 用
deleted表做条件判断，别再查基表（避免锁表、死锁、性能抖动） - 禁止在触发器里调
sp_executesql、链接服务器或 UDF，执行计划不可控 - 示例逻辑：
IF EXISTS (SELECT 1 FROM deleted WHERE role = 'admin') BEGIN RAISERROR('管理员用户禁止硬删除', 16, 1); RETURN; END ELSE DELETE u FROM users u INNER JOIN deleted d ON u.id = d.id;
TRUNCATE 和 DROP 怎么办？它们根本不走 DML 触发器
TRUNCATE TABLE 是 DDL 操作，绕过所有 DML 触发器；DROP TABLE 更是对象级变更，DML 触发器完全无感知。指望触发器拦住它们，等于没设防。
- 必须单独建 DDL 触发器：
CREATE TRIGGER tr_prevent_drop ON DATABASE FOR DROP_TABLE AS ... -
TRUNCATE无法用 DDL 触发器捕获（SQL Server 不支持FOR TRUNCATE），只能靠权限控制：REVOKE ALTER, TRUNCATE ON users TO [public]; - 高危表建议设为只读模式或启用
READ_ONLY文件组，比纯触发器更可靠 - 开发/运维流程上强制要求：删数据必须走带审批的存储过程，而非直连执行 DELETE
容易被忽略的细节和兜底手段
触发器不是银弹。它生效的前提是连接没绕过它——比如用 bcp、SSIS 或某些 ORM 的 bulk 操作，可能跳过触发器逻辑；另外，disallow results from triggers 选项若为 0，触发器里意外输出结果集会导致应用解析失败。
- 检查实例配置：
SELECT name, value_in_use FROM sys.configurations WHERE name LIKE 'disallow results from triggers'; - 别依赖
USER_NAME()或HOST_NAME()做权限判断——连接池常用固定账号，主机名在容器里也不稳定 - 真正的防护链是：应用层软删除字段（如
deleted_at） + 数据库层 INSTEAD OF + 权限最小化 + 只读副本 + 定时备份校验 - 最危险的不是写错触发器，而是以为建了它就万事大吉，结果某天凌晨被一条
TRUNCATE TABLE orders清空半年订单
