在数据库运维中，表结构变更（DDL操作）如果缺乏监控，很容易在无人感知的情况下破坏应用兼容性。虽然多数关系型数据库没有像数据行变更那样直观的表级DDL触发器，但我们可以通过组合系统表、存储过程和事件调度器，构建一套轻量级的变更预警机制。
为什么原生SQL触发器无法直接捕获DDL
标准SQL中的触发器（Trigger）通常分为BEFORE/AFTER INSERT、UPDATE、DELETE，它们只响应DML操作。以MySQL为例，CREATE TABLE、ALTER TABLE、DROP COLUMN等属于DDL语言，并不在触发器的监听范围内。很多初学者尝试写CREATE TRIGGER trg_ddl BEFORE ALTER ON table_name，这种语法在主流库中都是不被支持的。
要实现表结构变更预警，我们必须换一个思路：不直接拦截DDL，而是周期性地比对元数据。数据库的系统库（如information_schema）中存放了所有表的字段、索引、约束定义，只要把上次扫描的结果和本次结果做差异分析，就能知道谁动了结构。
基于快照比对的监控方案设计
整体流程分为三步：首先建一张历史结构表，保存每次采集的字段定义；然后用存储过程抓取当前information_schema内容并与之比对；最后用事件调度器定时运行该过程，发现差异就写入预警表。
下面是一张核心表的设计示例，用于记录字段级快照：
| 字段名 | 类型 | 说明 |
|---|---|---|
| table_name | varchar(64) | 被监控的表名 |
| column_name | varchar(64) | 列名 |
| data_type | varchar(32) | 数据类型 |
| snapshot_time | datetime | 快照时间 |
通过这种结构，我们可以快速定位某个表的某个字段在两次采集之间是否被修改类型或删除。
存储过程实现差异检测
以下MySQL存储过程演示了如何比对当前字段信息与最近一次快照，并将变更插入预警表。注意代码中的小于号和大于号都已转义。
DELIMITER $$
CREATE PROCEDURE check_ddl_change()
BEGIN
-- 查找当前存在但快照中没有的字段（新增）
INSERT INTO ddl_alert(table_name, column_name, change_type, alert_time)
SELECT c.table_name, c.column_name, 'ADD', NOW()
FROM information_schema.columns c
WHERE c.table_schema = 'test_db'
AND NOT EXISTS (
SELECT 1 FROM column_snapshot s
WHERE s.table_name = c.table_name
AND s.column_name = c.column_name
AND s.snapshot_time = (SELECT MAX(snapshot_time) FROM column_snapshot)
);
-- 查找快照中有但当前没有的字段（删除）
INSERT INTO ddl_alert(table_name, column_name, change_type, alert_time)
SELECT s.table_name, s.column_name, 'DROP', NOW()
FROM column_snapshot s
WHERE s.snapshot_time = (SELECT MAX(snapshot_time) FROM column_snapshot)
AND NOT EXISTS (
SELECT 1 FROM information_schema.columns c
WHERE c.table_schema = 'test_db'
AND c.table_name = s.table_name
AND c.column_name = s.column_name
);
END$$
DELIMITER ;
这个过程只覆盖了字段增减，实际生产中还可以扩展比对data_type、character_maximum_length等属性，捕捉修改类型的隐性变更。存储过程逻辑清晰，执行计划稳定，适合在从库上低频运行。
为了模拟“触发器”的自动响应，我们用事件调度器每隔十分钟调用一次上述过程：
CREATE EVENT IF NOT EXISTS ev_ddl_check ON SCHEDULE EVERY 10 MINUTE DO CALL check_ddl_change();
预警消息的推送方式
当ddl_alert表中出现新记录，就说明发生了结构变更。简单的做法是由外部脚本轮询该表并发送邮件或Webhook；若数据库版本支持，也可在存储过程内调用用户自定义函数通过HTTP向外通知。
相比直接开启general log或审计插件，这种快照比对方式对性能影响极小，且能精确给出变更列与变更类型。对于不想引入重量级审计系统的团队，是一种务实的DDL监控补充手段。
方案局限与注意事项
该方案并非实时拦截，最短监控间隔取决于事件频率，因此无法阻止恶意ALTER，只能做到及时发现。另外，information_schema在部分云数据库中被限制访问频率，调度间隔设置过短可能触发限流。
若业务对结构变更有强管控需求，仍建议结合 Liquibase、Flyway 等迁移工具做审批流，将本文方案作为兜底预警，而非唯一防线。