mysql 8.0 无内置表记录 ddl 历史，必须依赖 binlog 解析（需 binlog_format=statement/mixed 且启用 rows_query_log_events）或 server_audit 插件捕获，二者均不记录失败操作、执行者 ip 及结构变更前快照。
MySQL 8.0 本身不保存 DDL 操作的历史记录，information_schema 和 performance_schema 都不存“谁在什么时候改了哪张表的哪个字段”。想查到真实可追溯的 DDL 历史，必须依赖外部机制——要么日志解析，要么插件捕获，没有内置表或视图能直接 SELECT 出来。
用 mysqlbinlog 解析 binlog 查 DDL（最常用、最可靠）
binlog 是 MySQL 中唯一默认开启（且生产环境必开）的、能覆盖所有成功 DDL 的持久化来源。但注意：它只记录最终生效的语句，不记录失败操作，也不含执行者 IP 或应用名。
-
binlog_format = ROW时，DDL 仍以 statement 形式写入，所以mysqlbinlog --verbose能看到原始CREATE TABLE或ALTER TABLE；但binlog_format = STATEMENT在 8.0.30+ 已被标记为 deprecated，不推荐 - 必须启用
binlog_rows_query_log_events = ON（5.6.2+ 支持），否则--verbose不显示原始 SQL，只看到 event header - 执行命令示例：
mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.000012 | grep -A2 -B2 -i "alter table\|create table\|drop table"，-A2 -B2是为了带上下文时间戳 - 常见坑：直接
grep "ALTER"会漏掉带换行或注释的语句；binlog 文件可能已轮转，得先SHOW BINARY LOGS确认文件名范围
用 server_audit 插件实时捕获 DDL（需手动部署）
MySQL 社区版不带官方 audit_log（那是企业版），但可用兼容的 server_audit 插件（MariaDB 开发，MySQL 8.0 可用）。它能记录 ALTER USER、CREATE DATABASE 等，但对 ALTER TABLE 的字段级变更无感知。
- 安装后必须设
server_audit_events = 'QUERY'（不是QUERY_DDL，那个值不存在），否则ALTER TABLE不进日志 - 日志默认输出到
server_audit.log（在datadir下），格式是纯文本，类似：20260602 10:22:33,localhost,admin,QUERY,ALTER TABLE orders ADD COLUMN status VARCHAR(20) - 不记录失败 DDL（比如权限不足的
ERROR 1142），这点和general_log一样 - 插件启用后每条 DDL 触发一次磁盘写，高频场景下 I/O 明显上涨，别长期开着
为什么不能靠 general_log 审计 DDL？
虽然 general_log 能记下 ALTER TABLE，但它不是审计工具——它是调试开关，开起来就是“全量日志洪流”，生产环境开一小时就可能填满磁盘。
- 必须设
log_output = 'FILE'（TABLE不支持，否则会报错Table 'mysql.general_log' doesn't exist） - 日志里没有结构化字段，只能靠
grep -iE "(create|alter|drop).*table"硬匹配，但容易误中CREATE USER或DROP PROCEDURE - 不记录执行失败的 DDL，也不记录连接断开前未发送完的语句
- 性能影响极直接：QPS 过 300 时，机械盘或低 IOPS 云盘上
fsync就会成为瓶颈
真正落地的 DDL 审计，从来不是“查一个日志”，而是组合动作：用 binlog 回溯已发生的变更，用 server_audit 监控当前流量，再配合应用层发布平台（如 Flyway）锁定操作人和上下文。最容易被忽略的一点是：所有这些手段都**不记录 DDL 执行前的表结构快照**——你想知道“字段 X 是从 INT 改成 BIGINT 的”，得自己存历史 SHOW CREATE TABLE 结果，或者用 information_schema.COLUMNS 定时比对哈希值。
