INSTEAD OF DELETE 触发器是SQL Server中唯一能同步阻止误删的机制，因其在删除前执行且不自动执行原操作；AFTER DELETE无法恢复已删数据，TRUNCATE/DROP则完全不触发它。
INSTEAD OF DELETE 触发器能真正阻止 DELETE，但只对 DELETE 语句生效，且必须显式不执行删除逻辑——否则数据照删。
为什么不能用 AFTER DELETE 触发器防误删
AFTER DELETE 触发器运行时，行记录已从表中物理移除，deleted 表虽存在，但无法恢复原始数据。此时抛异常只会让事务失败，而数据早已丢失。
常见错误现象：触发器里写 RAISERROR('禁止删除', 16, 1) 后没加 ROLLBACK，结果日志报错、应用以为失败，实际数据已被清空。
正确做法只有一种：拦截必须发生在删除动作执行前，即只能用 INSTEAD OF DELETE 或（在支持的版本中）BEFORE DELETE —— SQL Server 不提供原生 BEFORE 触发器，所以 INSTEAD OF 是唯一同步拦截点。
INSTEAD OF DELETE 触发器里必须写什么
它不自动执行原操作，而是完全替代。你写什么，就执行什么；你什么都不写，数据就一动不动。
- 最简防护：空
BEGIN END块，或仅RAISERROR('禁止删除', 16, 1); RETURN; - 若需放行部分数据（如非管理员用户），必须显式写
DELETE语句，且目标要明确关联deleted表，例如：DELETE u FROM users u INNER JOIN deleted d ON u.id = d.id WHERE d.role != 'admin' - 严禁在触发器内再写
DELETE FROM users—— 会递归触发自身，SQL Server 报错：Maximum stored procedure, function, trigger, or view nesting level exceeded (limit 32) - 权限判断别依赖
USER_NAME()或SUSER_SNAME()做白名单，应用连接池常用固定账号，容易被绕过；应结合PROGRAM_NAME()或CONTEXT_INFO()区分人工操作与归档脚本
TRUNCATE TABLE 和 DROP TABLE 完全不受影响
TRUNCATE TABLE 是 DDL 操作，不生成 deleted 表，也不触发任何 DML 触发器。建了 INSTEAD OF DELETE 对它毫无作用。
DROP TABLE 同理，需单独创建 DDL 触发器：CREATE TRIGGER tr_block_drop ON DATABASE FOR DROP_TABLE，且必须满足三个条件才真正拦截：
- 触发器状态为启用：
SELECT is_disabled FROM sys.triggers WHERE name = 'tr_block_drop'返回 0 - 解析对象名必须用
EVENTDATA()，OBJECT_NAME()在 DDL 触发器中返回NULL；正确写法：CAST(EVENTDATA() AS XML).value('(/EVENT_INSTANCE/ObjectName)[1]', 'sysname') -
RAISERROR级别必须 ≥16，且紧跟ROLLBACK；级别 10 的错误只是警告，DROP仍会成功
容易被忽略的性能与兼容性陷阱
触发器是同步执行的，一旦慢，整个 DELETE 就卡住。以下操作极易拖垮性能：
- 在触发器里查大表（比如百万级订单表验证用户状态）
- 调用链接服务器、
sp_executesql或标量 UDF - 用
SELECT COUNT(*) FROM base_table做行数比对——应改用EXISTS或缓存字段（如加is_deletable BIT DEFAULT 1） -
deleted表的字符串字段比较未指定排序规则，旧版本可能因默认用服务器级排序规则导致匹配失败，应显式加COLLATE DATABASE_DEFAULT
真正可靠的防护不是靠一个触发器兜底，而是权限隔离为主（禁用非 DBA 账号的 DROP/TRUNCATE 权限）、触发器为辅、配合备份与快速恢复机制——因为触发器本身可被禁用、可被高权限用户绕过，它只是最后一道审计+拦截防线，不是保险柜。
