DDL变更必须用数据库原生DDL监控机制：SQL Server用ON DATABASE DDL触发器（FOR CREATE/ALTER/DROP TABLE），禁用邮件或shell调用；PostgreSQL用event trigger+NOTIFY异步通知；MySQL 5.7+仅能轮询performance_schema.events_statements_history表。
DDL 变更无法靠 AFTER INSERT 或 BEFORE UPDATE 捕获——这些是 DML 触发器，对 CREATE TABLE、ALTER TABLE 无效。必须用数据库原生支持的 DDL 监控机制，否则预警永远收不到。
SQL Server 必须用 ON DATABASE 的 DDL 触发器
只有 CREATE TRIGGER ... ON DATABASE FOR CREATE_TABLE, ALTER_TABLE, DROP_TABLE 能稳定捕获结构变更。常见错误是写成 ON TABLE 或误用 AFTER——DDL 触发器只认 FOR，AFTER 和 INSTEAD OF 都不合法。
- 触发器内严禁调用
sp_send_dbmail或EXEC xp_cmdshell：会阻塞整个 DDL 事务，导致ALTER TABLE卡死 - 正确做法是插入一条记录到监控表（如
ddl_change_log），字段至少含EVENTDATA()返回的 XML、DatabaseName、ObjectName、EventType - 记得过滤
tempdb：在触发器开头加IF EVENTDATA().value('(/EVENT_INSTANCE/DatabaseName)[1]', 'sysname') = 'tempdb' RETURN - 权限要提前配好：
CREATE DATABASE DDL TRIGGER权限 +ALTER ANY DATABASE（若需跨库写日志）
PostgreSQL 得用 event trigger + NOTIFY 异步发信号
PG 没有 DDL 触发器，但 CREATE EVENT TRIGGER 配合 pg_notify() 是唯一可行路径。它不介入事务，只在提交后发通知，不会拖慢 CREATE INDEX 这类操作。
-
CREATE EVENT TRIGGER必须由超级用户执行，且不能在事务块里运行（否则报错ERROR: cannot create event trigger within transaction block） - 监听
ddl_command_end事件，用pg_event_trigger_ddl_commands()提取对象名；若要抓DROP，得额外监听sql_drop并用pg_event_trigger_dropped_objects() -
NOTIFY的 payload 限制 8000 字节：别传完整COMMENT ON COLUMN文本，只传object_identity和operation - 客户端必须长连接并执行
LISTEN schema_changes，断连即丢事件——生产环境务必加序号表或 WAL 位置跟踪断点
MySQL 5.7+ 只能轮询 performance_schema.events_statements_history
MySQL 原生无 DDL 触发器，binlog 在 ROW 格式下根本不记录 CREATE/ALTER，所以别试解析 binlog。唯一轻量方案是查 performance_schema 表，但默认关闭且易截断。
- 先启用：
UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME = 'events_statements_history'; - 该表只保留最近 10000 条，且
sql_text可能被截断（尤其带长注释的ALTER TABLE）；建议配合digest_text和event_name做双重匹配 - 轮询 SQL 示例：
SELECT * FROM performance_schema.events_statements_history WHERE event_name LIKE 'statement/sql/%' AND sql_text REGEXP '^(CREATE|ALTER|DROP) +TABLE' ORDER BY timer_start DESC LIMIT 10 - 必须加时间窗口去重：用
WHERE timer_start > @last_check_time+ 更新@last_check_time，否则重复告警
所有数据库都禁用时间戳做逻辑主键
跨库同步元数据时，别用 EVENT_TIME 或 timer_start 当唯一标识——高并发下毫秒级时间可能重复，且不同库时钟不同步。真正可靠的键是业务语义组合。
- 统一用
MD5(object_name || '.' || schema_name || '.' || database_name)生成逻辑主键，确保同个表在不同实例中 ID 一致 - MySQL 的
events_statements_history没有 schema 字段，得从sql_text里正则提取（如CREATE TABLE `mydb`.`users`） - SQL Server 的
EVENTDATA()XML 里SchemaName节点可能为空（比如建在 dbo 下），要 fallback 到DatabaseName+ObjectName - PostgreSQL 的
object_identity返回形如"public"."users"，直接用即可，但注意双引号和大小写敏感
实际落地最易忽略的是“事件丢失”问题：SQL Server 触发器里写日志表失败（比如磁盘满）、PG 的 LISTEN 连接意外断开、MySQL 轮询脚本 crash 后没重启——这些都会让预警链路静默失效。必须给每种机制配独立健康检查，而不是只盯着触发器是否创建成功。
