INSTEAD OF DELETE 触发器可拦截 DELETE 语句但无法拦截 TRUNCATE TABLE，且不支持含级联外键的表；其本质是替代而非阻止删除操作，需显式回滚或空逻辑实现防护。
直接结论：用 INSTEAD OF DELETE 触发器可以彻底拦截 DELETE 语句，但不能拦截 TRUNCATE TABLE，且对含级联外键的表不生效。
为什么 INSTEAD OF DELETE 能拦住删除但拦不住清空
因为 INSTEAD OF DELETE 是在 SQL Server 解析到 DELETE 语句时介入，直接跳过原操作、只执行触发器体内的逻辑；而 TRUNCATE TABLE 不走 DML 流程，不触发任何 DML 触发器，也不生成 DELETED 表，属于 DDL 级别操作。
-
DELETE FROM A→ 触发INSTEAD OF DELETE→ 触发器内没写实际删除逻辑 → 数据保留 -
TRUNCATE TABLE A→ 完全绕过所有 DML 触发器 → 表被清空（需单独用 DDL 触发器或权限控制防范） - 如果表 A 的某个字段是其他表的外键，并设置了
ON DELETE CASCADE，则 SQL Server 明确禁止在此表上创建INSTEAD OF DELETE触发器，建触发器会报错：Msg 3724, Level 16, State 1: Cannot create INSTEAD OF DELETE trigger on table 'A' because the table has a foreign key with cascaded DELETE.
INSTEAD OF DELETE 触发器里该写什么逻辑
核心原则：你写了什么，就执行什么；你什么都不写，就等于什么都没删。它不是“阻止后报警”，而是“替代掉整个删除动作”。
- 最简防护写法就是空
BEGIN ... END块，或只加一行RAISERROR('禁止删除', 16, 1)+ROLLBACK（注意：必须显式回滚，否则批处理可能继续） - 若想记录谁删了什么，可从
DELETED表查数据，插入日志表：INSERT INTO DeleteLog SELECT *, SUSER_SNAME(), GETDATE() FROM DELETED - 不要在触发器里写
DELETE FROM ...—— 这会递归触发自己，导致无限循环（SQL Server 会报错：Maximum stored procedure, function, trigger, or view nesting level exceeded (limit 32).）
容易被忽略的兼容性与行为细节
这些点不报错，但会导致逻辑失效或行为异常：
-
DELETED表结构严格匹配触发器所依附的表或视图定义，不是原始基表结构。如果在视图上建INSTEAD OF DELETE，DELETED表只含视图 SELECT 列，不含基表隐藏字段 - 排序规则问题：SQL Server 2012–2014 中，
DELETED表默认使用服务器级排序规则，而非数据库DATABASE_DEFAULT，可能导致字符串比较失败（如WHERE info COLLATE DATABASE_DEFAULT = 'a'才安全） - 触发器中不能调用某些函数，比如
GETDATE()可以，但NEWID()在部分旧版本中受限；涉及大对象（text/ntext）字段时，DELETED表中对应列为NULL，需用TEXTPTR配合处理
真正管用的防护组合建议
单靠一个触发器防误删是脆弱的。生产环境应分层设防：
- 对核心表，禁用普通账号的
DELETE权限，只开放SELECT和必要UPDATE；DBA 用带审批流程的专用账号执行删操作 - 用
INSTEAD OF DELETE拦常规应用代码的误调用，同时搭配AFTER DELETE记录审计日志（注意：二者不能共存于同一张表） - 定期备份 + 启用
READ_COMMITTED_SNAPSHOT减少阻塞，比事后恢复更可靠 - 测试阶段务必验证：触发器是否在事务中被正确回滚？是否影响
BULK INSERT或 SSIS 导入？这些场景下触发器默认仍会激活
