TRUNCATE无法被普通触发器捕获，因其属DDL操作；SQL Server支持DDL触发器拦截，MySQL/PG需依赖日志轮询或权限控制；最可靠方案是回收DROP（MySQL）、TRUNCATE（PG）或ALTER（SQL Server）权限。
Truncate 无法被普通触发器捕获，这是根本限制
SQL 标准中 TRUNCATE TABLE 是 DDL 操作（尽管行为类似 DML），**绝大多数数据库（MySQL、PostgreSQL、SQL Server）都不支持在 TRUNCATE 上创建 AFTER 或 BEFORE 触发器**。你写 CREATE TRIGGER ... ON table_name FOR TRUNCATE 会直接报错，比如 MySQL 返回 ERROR 1415 (0A000): Not allowed to return a result set from a trigger，而 PostgreSQL 根本不解析 TRUNCATE 为触发事件类型。
所以想靠传统行级/语句级触发器“拦截” TRUNCATE —— 行不通。这不是配置问题，是引擎设计层面的限制。
替代方案：用 DDL 触发器（仅限 SQL Server）或系统视图轮询（MySQL/PG）
SQL Server 是唯一原生支持 DDL 触发器的主流数据库，可捕获 TRUNCATE_TABLE 事件：
CREATE TRIGGER prevent_truncate_on_users
ON DATABASE
FOR TRUNCATE_TABLE
AS
BEGIN
IF ORIGINAL_LOGIN() NOT IN ('sa', 'admin_user')
AND EVENTDATA().value('(/EVENT_INSTANCE/ObjectName)[1]', 'sysname') = 'users'
BEGIN
RAISERROR('Truncating [users] is prohibited for this login.', 16, 1)
ROLLBACK
END
END
注意：EVENTDATA() 必须在触发器内立即调用；ROLLBACK 有效，但仅对当前会话生效；该触发器需建在 DATABASE 级别，不是表级别。
MySQL 和 PostgreSQL 没有 DDL 触发器。可行做法是：
- 开启通用查询日志（
general_log=ON）或二进制日志（binlog_format=ROW+ 解析），但性能开销大、非实时 - 定期轮询
information_schema.TABLES中TABLE_ROWS突变（如从 10w 骤降到 0），再结合performance_schema.events_statements_history查最近执行的TRUNCATE语句 —— 这是事后审计，不能阻止操作 - PG 可用
pg_stat_activity+pg_stat_statements联查，但同样无法实时阻断
真正能禁止 Truncate 的生产级手段只有权限控制
最可靠、零延迟、无需轮询或日志解析的方式，是收回 TRUNCATE 所依赖的底层权限：
- MySQL：撤销
DROP权限（因为TRUNCATE内部会先DROP再重建表）：REVOKE DROP ON database.table FROM 'user'@'%' - PostgreSQL：撤销
TRUNCATE权限本身（9.5+）：REVOKE TRUNCATE ON TABLE users FROM app_user；旧版本需撤DELETE+ 禁用ON DELETE触发器干扰 - SQL Server：撤
ALTER权限（TRUNCATE需要表级ALTER），或更细粒度地用DENY TRUNCATE（注意：DENY 优先级高于 GRANT）
权限方式生效快、无兼容性风险，且所有客户端工具（包括 ORM 自动执行的 TRUNCATE）都会被统一拦截，返回明确错误如 ERROR 1142 (42000): TRUNCATE command denied。
DDL 监控落地时最容易被忽略的点
监控 TRUNCATE 不等于只盯语句文本 —— 它常被包装成其他形式：
- ORM 如 Django 的
Model.objects.all().delete()在空表上可能生成TRUNCATE（取决于后端和配置），但日志里只记DELETE - 某些 ETL 工具（如 DataGrip、Navicat）执行“清空表”功能时，实际发的是
TRUNCATE，但审计日志可能归类为“GUI action”，不落 SQL 文本 - MySQL 5.7+ 的
innodb_file_per_table=OFF下，TRUNCATE可能退化为DROP+CREATE，需同时监控DROP TABLE事件
真正在意数据安全的团队，不会只靠“监控到再告警”，而是把权限回收 + DDL 日志采集 + 应用层操作白名单三者叠在一起用。单点防御，在运维复杂度上升后大概率漏掉某条路径。
