必须用ON DATABASE的DDL触发器捕获表结构变更，语法为CREATE TRIGGER ... ON DATABASE FOR ALTER_TABLE等，仅FOR有效；需解析EVENTDATA() XML提取对象信息，并注意高权限用户可绕过。
不能直接用普通 DML 触发器（CREATE TRIGGER）捕获表结构变更，因为 DDL 操作（如 ALTER TABLE、DROP COLUMN）根本不会触发它们。
SQL Server 必须用 ON DATABASE 的 DDL 触发器
只有 CREATE TRIGGER ... ON DATABASE FOR CREATE_TABLE, ALTER_TABLE, DROP_TABLE 这类 DDL 触发器能响应结构变动。关键点：
-
FOR是必须写法，不是AFTER或INSTEAD OF—— 后两者在 DDL 场景下语法错误或无效 - 触发器内必须调用
EVENTDATA()解析 XML，从中提取ObjectName、ObjectType、TSQLCommand - 日志表字段建议含：
event_time（用SYSUTCDATETIME()）、event_type、object_name、schema_name、command_text（截断至 4000 字符防溢出） - 避免在触发器里做远程调用或复杂计算，否则会阻塞所有 DDL 执行
PostgreSQL 必须用 event trigger + pg_event_trigger_ddl_commands()
MySQL 不支持 DDL 触发器，而 PostgreSQL 需靠 event trigger，且仅 ddl_command_end 能拿到完整对象信息：
- 函数体必须用
SELECT * FROM pg_event_trigger_ddl_commands()获取结果集，不能只取一行 -
object_identity返回的是带双引号的全限定名（如"public"."users"），不能直接拼 SQL；schema_name是裸名（public） - 别依赖
current_query()——它返回的是内部格式字符串，可能含换行符或参数占位符，插入日志前至少要TRIM(BOTH ' ' FROM current_query()) - 触发器创建前，确保日志表已存在，且运行用户对日志表有
INSERT权限
MySQL 5.7+ 只能轮询 performance_schema.events_statements_history
MySQL 原生不提供 DDL 触发器，binlog 在 row 格式下也不记录 DDL，唯一可行路径是定时查系统表：
- 需先启用：
UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME = 'events_statements_history'; - 轮询语句示例：
SELECT SQL_TEXT, DIGEST_TEXT, EVENT_NAME, TIMER_START FROM performance_schema.events_statements_history WHERE EVENT_NAME LIKE 'statement/sql/%' AND SQL_TEXT REGEXP '^(CREATE|ALTER|DROP)\s+(TABLE|INDEX|COLUMN)' ORDER BY TIMER_START DESC LIMIT 10; - 问题明显：历史条目默认只保留 10000 条；
SQL_TEXT可能被截断；无法区分是哪个连接发起的 DDL - 生产环境建议配合外部采集（如
pt-query-digest抓 slow log + DDL 关键字）或强制走迁移工具（Flyway）
DDL 审计最易被忽略的一点：所有方案都拿不到“谁在应用层发起的变更”。USER() 或 CURRENT_USER 返回的是数据库登录账号，不是业务系统里的操作人。真要追溯到人，得靠部署流程卡口或中间件埋点，触发器本身做不到。
