MySQL不内置DDL变更历史记录，需依赖外部机制：一是应用层统一发布平台（如Flyway），二是代理层捕获（如ProxySQL），三是定时比对information_schema.COLUMNS哈希值监控漂移。
MySQL 没有内置表结构变更历史表
MySQL 本身不记录 ALTER TABLE、DROP COLUMN 这类 DDL 操作的历史，information_schema 和 performance_schema 都不保存“谁在什么时候改了什么字段”。想查变更记录，必须依赖外部机制。
常见错误现象：SHOW CREATE TABLE 只返回当前结构；SELECT * FROM information_schema.COLUMNS 只反映现状；开启 general_log 后日志爆炸且难过滤 DDL。
- 生产环境禁用
general_log（性能开销大，日志体积不可控） -
binlog_format = STATEMENT时，部分 DDL 可能在 binlog 中被重写或合并，丢失原始语句细节 - 即使开了
binlog_format = ROW，DDL 本身仍以 statement 模式记录，无法解析出字段级变更
靠 binlog 解析 DDL 日志要满足三个前提
MySQL 的 binlog 是最接近“审计日志”的现成资源，但直接读 mysqlbinlog 输出并不等于能还原变更历史——它只告诉你“发生了”，不告诉你“改前什么样”。
使用场景：已有 binlog 归档，且需回溯近一周内关键表的 DDL 操作（如误删字段后定位时间点）。
- 必须启用
log_bin = ON且保留足够天数的 binlog 文件 - 服务器需配置
binlog_rows_query_log_events = ON（5.6.2+），否则mysqlbinlog --verbose无法显示原始 SQL - 执行
mysqlbinlog --base64-output=DECODE-ROWS -v时，注意筛选ALTER TABLE/CREATE TABLE行，别被大量INSERT冲掉
真正可用的审计方案只有两种落地方式
不是“推荐几种工具”，而是实际跑得通的路径：要么在应用层拦截 DDL，要么用 MySQL 插件/代理做旁路捕获。中间方案（比如定时抓 SHOW CREATE TABLE 快照）只能发现“已发生”，无法定位操作人和上下文。
- 应用层控制：所有 DDL 必须走统一发布平台（如 Flyway/Liquibase），平台记录操作人、时间、SQL、影响行数，并拒绝直连客户端执行
ALTER - 代理层捕获：用
MySQL Router或ProxySQL在流量入口处记录含ALTER/DROP的语句，配合白名单过滤非管理账号 - 插件方案慎选：
audit_log插件（企业版）可记录 DDL，但开源版无此功能；社区替代品如macron或mysql-audit插件需编译安装，且 8.0.30+ 兼容性不稳定
监控表结构漂移的最小可行做法
如果连 binlog 都没开，又没法改架构，至少做到“及时发现异常变更”。这不是查历史，而是防下次。
参数差异：information_schema.COLUMNS 的 COLUMN_DEFAULT、IS_NULLABLE、DATA_TYPE 等字段变化，比表名/库名变更更易被忽略。
- 每天凌晨用脚本对比
SELECT TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME, DATA_TYPE, IS_NULLABLE, COLUMN_DEFAULT FROM information_schema.COLUMNS WHERE TABLE_SCHEMA NOT IN ('mysql','sys','performance_schema')的 MD5 值 - 把结果存到本地 SQLite，用
diff找出新增/删除/类型变更的字段行 - 避免查
TABLES表——它不包含字段级信息，漏掉MODIFY COLUMN这类静默变更
复杂点在于：同一张表在不同实例上结构可能合法不同（比如分库分表场景），所以哈希比对必须按实例维度隔离。没人会为这事写个微服务，但一个带锁的 shell 脚本 + cron 就够用。
