truncate table 不触发 dml 触发器，因其是 ddl 类操作、不逐行处理；须用 on database 级 ddl 触发器捕获 truncate_table 事件，配合 eventdata() 和显式 rollback 才能拦截。
SQL Server 的 DML 触发器拦不住 TRUNCATE TABLE
直接说结论：TRUNCATE TABLE 不会触发 AFTER 或 INSTEAD OF DML 触发器。它绕过行级日志、不走事务回滚路径，也不填充 deleted 逻辑表——DML 触发器根本收不到信号。
这不是配置问题，是 SQL Server 底层机制决定的：TRUNCATE 是 DDL 类语义（尽管语法像 DML），只释放数据页，不逐行操作，所以传统触发器监听不到。
- 执行
TRUNCATE TABLE orders后检查sys.dm_exec_sessions或触发器日志表，会发现完全没记录 -
DELETE FROM orders能被拦截，但TRUNCATE一跑就消失，连RAISERROR都没机会执行 - 别试用
IF EXISTS (SELECT * FROM deleted)判断——deleted表在 TRUNCATE 触发器里压根为空，甚至根本不会被构造
必须用 DDL 触发器捕获 DROP/TRUNCATE/ALTER 操作
SQL Server 支持 DDL 触发器，专门响应 CREATE、DROP、ALTER、TRUNCATE TABLE 这类语句。关键函数是 EVENTDATA()，它返回 XML 格式的事件上下文。
下面这个触发器能真正卡住 TRUNCATE TABLE：
CREATE TRIGGER tr_prevent_truncate
ON DATABASE
FOR DROP_TABLE, TRUNCATE_TABLE
AS
BEGIN
DECLARE @event_data XML = EVENTDATA();
DECLARE @obj_name SYSNAME = @event_data.value('(/EVENT_INSTANCE/ObjectName)[1]', 'SYSNAME');
DECLARE @login_name SYSNAME = @event_data.value('(/EVENT_INSTANCE/LoginName)[1]', 'SYSNAME');
<pre class="brush:php;toolbar:false;">IF @obj_name IN ('orders', 'users', 'transactions')
BEGIN
RAISERROR('TRUNCATE/DROP on %s is forbidden for %s', 16, 1, @obj_name, @login_name);
ROLLBACK;
ENDEND;
- 必须建在
ON DATABASE级别，不能建在单个表上 -
FOR DROP_TABLE, TRUNCATE_TABLE是两个独立事件，要一起写，否则漏掉一个就失效 -
ROLLBACK必须显式写，仅RAISERROR不会中止操作；DDL 触发器默认不自动回滚 - 注意权限：创建者需有
ALTER ANY DATABASE DDL TRIGGER权限，且账号不能被DISABLE TRIGGER
DDL 触发器的硬限制和绕过风险
DDL 触发器虽能拦 TRUNCATE，但不是银弹。它有明确的盲区和权限依赖：
- 只有
sysadmin或db_owner成员能禁用或删掉该触发器，普通账号执行DISABLE TRIGGER tr_prevent_truncate ON DATABASE会报错 - 如果用户用
db_owner权限登录，再执行TRUNCATE，触发器仍生效；但若他先DISABLE再TRUNCATE，就彻底绕过了 -
TRUNCATE TABLE在某些场景下不触发：比如通过sp_executesql动态拼接且未显式传参（如N'TRUNCATE TABLE ' + @table），EVENTDATA()可能取不到ObjectName - 不拦截
DBCC CHECKIDENT ... RESEED或直接删文件等物理操作，这些属于运维层面，得靠 OS 权限隔离
真正防住 TRUNCATE 的组合策略
单靠触发器永远有缝隙。生产环境必须叠加三层控制：
- 权限最小化：
REVOKE ALTER ON DATABASE::[your_db] FROM [app_user]，并确认app_user不在db_owner角色里 - DDL 触发器兜底：如上所写，同时监控
TRUNCATE_TABLE和DROP_TABLE，写入审计表而非仅报错 - 备份与恢复验证：每天自动执行
RESTORE HEADERONLY检查最近全备是否可用，并用DBCC PAGE抽样校验关键表页是否被清空过痕迹
最容易被忽略的是：DDL 触发器里的 EVENTDATA() 返回值在高并发下可能延迟几毫秒，若同一连接连续执行多个 TRUNCATE，第二个事件可能读到第一个的缓存 XML。上线前务必用 sp_whoisactive 配合压力脚本实测。
