TRUNCATE语句根本不会触发任何DML触发器，因其属于DDL操作，不逐行处理、不生成伪表、不走DML触发路径；必须改用DELETE才能激活触发器。
TRUNCATE 语句根本不会触发任何 DML 触发器 —— 不是漏了、没配好，而是 SQL 引擎压根不把它当 DML 看。
TRUNCATE 是 DDL，不是 DML
触发器只响应 INSERT、UPDATE、DELETE 这类 DML 操作；而 TRUNCATE TABLE 在绝大多数数据库（SQL Server、MySQL、PostgreSQL）中被归类为 DDL（数据定义语言）操作。它本质是“重建表结构+释放空间”，不逐行访问数据，也不生成事务日志中的行级变更记录。引擎连 inserted 或 deleted 表都不会构造，更不会走触发器注册路径。
- SQL Server 中，
TRUNCATE不触发AFTER或INSTEAD OF触发器，且无法回滚（除非在显式事务中） - MySQL 5.7+ 同样不触发
BEFORE/AFTER INSERT/UPDATE/DELETE触发器；TRUNCATE会隐式提交当前事务 - PostgreSQL 的
TRUNCATE也不激活行级触发器，仅支持表级事件触发器（需显式声明FOR TRUNCATE，且仅限BEFORE）
为什么看起来像“没捕获”，其实是“没机会捕获”
常见误判场景：
- 你在
AFTER DELETE触发器里写了清理逻辑，但用了TRUNCATE→ 触发器完全不执行，清理逻辑自然失效 - 日志表没新增记录，
sys.dm_exec_trigger_stats（SQL Server）或information_schema.triggers（MySQL）里对应触发器的exec_count为 0 → 不是卡住或失败，是根本没被调用 - 用
OUTPUT子句或inserted表查不到数据 → 因为TRUNCATE不产生这些上下文对象
想让清空动作可审计或联动，该用什么替代？
如果业务需要“清空 + 同步记录/通知/校验”，必须绕过 TRUNCATE 的机制限制：
- 改用
DELETE FROM table_name：能触发 DML 触发器，但注意性能和事务日志开销；大表建议分批（如WHERE id BETWEEN ...） - 手动补审计逻辑：在存储过程中先
INSERT INTO audit_log SELECT COUNT(*) FROM table_name，再执行TRUNCATE，把“意图”和“动作”拆开 - MySQL 8.0+ 可考虑
CREATE EVENT定时检查表行数突变，但非实时，且无法区分TRUNCATE和大批量DELETE - SQL Server 可启用
CHANGE TRACKING或TEMPORAL TABLE，但它们也不捕获TRUNCATE，仅对 DML 生效
真正难处理的点不在语法层面，而在于：你依赖触发器做联动的前提，本身就排除了 TRUNCATE 的使用资格。一旦选了它，就得接受“无感知、无回调、不可逆”的事实 —— 这不是 bug，是设计契约。
