MySQL触发器如何检测表结构变动？

本文共计825个文字，预计阅读时间需要4分钟。

数据库触发器只对DML语句（如INSERT、UPDATE、DELETE）生效，对DDL语句（如ALTER TABLE、DROP COLUMN、ADD INDEX）无效。这是MySQL内核层面的限制，而非语法错误或权限问题。

常见错误现象：
– 在users表上创建了AFTER ALTER触发器（语法直接报错）
– 以为给information_schema.TABLES建触发器能捕获结构变更（该库是只读视图，不支持触发器）
– 尝试用CREATE TRIGGER ... ON information_schema.COLUMNS（同样语法拒绝）

根本原因：触发器机制运行在存储引擎层之上，而DDL操作需先锁表、修改元数据、重载表定义，整个过程绕过触发器执行路径。

替代方案：监听binlog或轮询information_schema

想感知结构变化，得跳出触发器思维。两种主流做法：

• 解析binlog：启用binlog_format = ROW后，DDL语句仍以QUERY_EVENT形式记录（非ROW事件），可用mysqlbinlog工具过滤ALTER、CREATE等关键词；注意DDL不会出现在ROW模式的event中，必须用STATEMENT或MIXED模式
• 定时比对information_schema.COLUMNS：比如每5分钟查一次SELECT COLUMN_NAME, DATA_TYPE FROM information_schema.COLUMNS WHERE TABLE_SCHEMA='mydb' AND TABLE_NAME='orders'，和上次结果做diff；缺点是延迟高、无法精确定位执行者

性能影响：轮询information_schema在大库上可能触发MDL锁等待；binlog解析需额外服务（如Canal、Maxwell），增加运维复杂度。

为什么审计表或触发器日志表也救不了DDL监控

有人试图在触发器里写日志表来“间接推断”结构变更——比如发现某列突然写入NULL而之前不允许为空，就猜测被MODIFY COLUMN了。这种做法不可靠：

• 字段默认值变更、注释修改、索引增删完全不经过DML，日志表毫无痕迹
• ALTER TABLE ... CHANGE COLUMN可能重命名字段，旧字段名不再出现，但新字段名的首次写入无法区分是业务数据还是结构变更导致
• 并发DDL+DML时，时间戳顺序和实际执行顺序可能不一致，导致误判

本质问题：DML日志和DDL行为之间没有因果链，强行关联只会引入噪声。

真正需要DDL审计时，该用什么

生产环境真要监控结构变更，优先考虑数据库代理层或权限管控：

• 把ALTER、DROP等权限收归DBA账号，所有变更走工单系统，由审批流驱动
• 用proxySQL或MaxScale拦截SQL，匹配^ALTER\s+TABLE正则并记录来源IP、用户、时间
• MySQL 8.0+可开启audit_log插件，配置audit_log_policy=ALL，它会记录DDL（但不包括具体变更内容，如改了哪个字段）

最易被忽略的一点：即使你用脚本轮询information_schema，也要注意TABLE_SCHEMA和TABLE_NAME大小写敏感性——在Linux下它们是大小写敏感的，拼错就查不到结果。