高危操作需用DDL触发器或专用审计扩展捕获：SQL Server用DDL触发器+EVENTDATA()提取事件上下文；PostgreSQL启用pg_audit按角色/对象/操作三层过滤；MySQL 8.0+依赖audit_log插件或临时开启general_log并比对应用日志。
高危操作无法被DML触发器捕获，必须用DDL触发器或原生审计
标准 SQL 的 INSERT/UPDATE/DELETE 触发器对 DROP TABLE、TRUNCATE、ALTER TABLE、GRANT 等高危操作完全无感。试图在业务表上建 AFTER DELETE 触发器来审计 TRUNCATE users，结果只会是日志空白——因为 TRUNCATE 不走 DML 流程，不触发任何行级触发器。MySQL 甚至会直接报错 ERROR 1451: Cannot delete or update a parent row（若误配了外键+触发器），而非记录动作。
SQL Server 用 DDL 触发器 + EVENTDATA() 捕获 schema 变更
这是目前最可控的双重核对起点：DDL 触发器能真正响应 CREATE/DROP/ALTER 事件，并通过 EVENTDATA() 提取完整上下文。但必须注意三点：
- 触发器必须建在数据库或服务器级别（
ON DATABASE或ON ALL SERVER），不能建在单张表上 -
EVENTDATA()返回 XML，需用.value()提取关键字段，例如：EVENTDATA().value('(/EVENT_INSTANCE/EventType)[1]', 'nvarchar(100)') - 必须显式判断
EVENTDATA().value('(/EVENT_INSTANCE/ObjectName)[1]', 'sysname')是否命中敏感表名（如'users'或'config'），否则所有 DDL 都进日志，噪音爆炸
PostgreSQL 启用 pg_audit 扩展实现语句级双重过滤
pg_audit 不是触发器，但它能补足触发器做不到的事：按角色、对象、操作类型三层过滤，且日志独立落盘，不依赖事务。启用后，你可以这样配置双重核对逻辑：
- 第一层：在
postgresql.conf中设pgaudit.log = 'ddl, role'，捕获所有 DDL 和权限变更 - 第二层：在
pgaudit.log_relation = 'on'基础上，用pgaudit.log_parameter = 'on'记录实际执行的 SQL 文本，方便比对是否含WHERE条件（防误删） - 必须禁用
pgaudit.log_catalog = 'off'，否则系统表操作日志会淹没真实业务行为
注意：pg_audit 日志默认写入 CSV 文件，不是数据库表；若要入库分析，得用外部脚本定时 COPY，不能指望触发器自动搬运。
MySQL 8.0+ audit_log 插件 + general_log 临时兜底的组合策略
MySQL 社区版没有 pg_audit 那样的扩展机制，audit_log 插件（企业版）是唯一正解；开源版只能靠 general_log 临时顶上——但代价极高：
-
general_log = ON会记录每条语句（包括SELECT），I/O 压力翻倍，仅限短时排查，上线即关 - 真正可用的双重核对方式是：开启
audit_log插件后，在其输出中 grep'DROP\|TRUNCATE\|GRANT\|REVOKE'，再与应用层调用日志（如 Java 的DataSourceProxy日志）做时间戳比对 - 别碰
PERFORMANCE_SCHEMA.events_statements_history_long——它默认关闭，开启后内存占用激增，且只保留最近 10000 条，高危操作可能已被覆盖
最容易被忽略的是：所有这些方案生成的日志本身都是敏感数据，audit_log_file 权限必须设为 600，pg_audit.log_path 目录需由专用 OS 用户拥有——否则审计日志反而成了最大泄露面。
