MySQL触发器仅响应INSERT、UPDATE、DELETE等DML语句，无法捕获ALTER TABLE等DDL操作，因DDL绕过触发器执行路径；替代方案包括解析binlog（需STATEMENT/MIXED模式）或定时轮询information_schema。
MySQL触发器不能响应ALTER TABLE等DDL操作
触发器只对DML语句（INSERT、UPDATE、DELETE）生效，对ALTER TABLE、DROP COLUMN、ADD INDEX这类DDL语句完全无感知。这是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下它们是大小写敏感的，拼错就查不到结果。
