能，INSTEAD OF DELETE 可真正阻止删数据，但它仅拦截 DELETE 语句，不作用于 TRUNCATE TABLE 或 DROP TABLE；必须在触发器中显式编写逻辑（如 RAISERROR 或条件 DELETE），否则原记录完全保留。
SQL Server 里 INSTEAD OF DELETE 能真正阻止删数据吗
能，但只对 DELETE 语句生效，且必须显式写逻辑——它不自动执行原操作，而是完全替代。只要触发器里不写 DELETE FROM ...，数据就一动不动。
常见误区是以为建了 INSTEAD OF DELETE 就高枕无忧，结果发现 TRUNCATE TABLE 或 DROP TABLE 完全不受影响。这两者根本不会触发任何 DML 触发器。
-
TRUNCATE是 DDL 操作，绕过触发器、日志更少、无法回滚（除非在事务中） -
DROP TABLE属于对象定义变更，SQL Server 的 DDL 触发器可捕获，但需单独创建ON DATABASE FOR DROP_TABLE类型 - 触发器只对当前绑定的表/视图起作用，不能跨库、不能继承
怎么写一个可靠又不拖慢性能的 INSTEAD OF DELETE 触发器
核心原则：不查大表、不调外部资源、不嵌套事务、不依赖会话上下文做权限判断（容易被绕过）。
示例场景：禁止直接删除 sys_users 表中 role = 'admin' 的记录：
CREATE TRIGGER tr_prevent_admin_delete
ON sys_users
INSTEAD OF DELETE
AS
BEGIN
IF EXISTS (SELECT 1 FROM deleted WHERE role = 'admin')
BEGIN
RAISERROR('管理员用户禁止硬删除', 16, 1);
RETURN;
END
<pre class='brush:php;toolbar:false;'>-- 允许其他记录正常删除
DELETE u FROM sys_users u
INNER JOIN deleted d ON u.id = d.id
WHERE d.role != 'admin';END;
- 用
deleted表做条件判断，避免再查基表——这是唯一安全、高效的方式 - 不要在触发器里写
IF USER_NAME() = 'sa' RETURN这类逻辑：应用连接池常用固定账号，权限校验应前置到连接层或代理层 - 别在触发器里调
sp_executesql或访问链接服务器，执行计划不可控，容易锁表
为什么 AFTER DELETE 触发器不适合防误删
AFTER DELETE 触发器在数据已经删完之后才运行，此时行记录从表中消失，deleted 表虽存在，但已无法回滚原始操作（除非整个事务未提交）。
更危险的是：如果触发器里再抛异常，只会让事务失败，但数据早已不在——你看到的是“报错了”，实际是“删完了再报错”。
-
AFTER触发器适合审计、归档、通知，不适合拦截 - 想补救？只能靠备份或 binlog（MySQL）/ log backup（SQL Server），不是实时防护
- 某些 ORM 会把
DELETE包进显式事务，这时AFTER报错确实能回滚，但前提是开发者没关自动提交，且没用SET IMPLICIT_TRANSACTIONS OFF
真正防住误删，光靠触发器远远不够
INSTEAD OF 触发器只是最后一道数据库内防线，它挡不住高权限账号手动禁用触发器、绕过视图直连基表、或用 BULK INSERT + TRUNCATE 组合拳。
必须配合三件事：
- 用
REVOKE DELETE ON sys_users FROM [app_user]收紧权限，让普通账号连DELETE都发不出 - 关键表改用视图暴露，只给应用账号查/改视图权限，在视图上建
INSTEAD OF触发器，物理表彻底隐藏 - 开启 SQL Server 的
default trace或扩展事件（XEvent），监控object_altered和sql_batch_completed，匹配TRUNCATE、DROP关键词并告警
最易被忽略的一点：所有防御措施都假设 DBA 不会手抖。所以生产库的 sa 登录必须绑定 MFA，且所有高危操作强制走审批工单系统——触发器拦不住人，制度才能。
