能记录CREATE/ALTER/DROP，但默认不开启，粒度粗、易撑磁盘，仅宜临时排查；需设log_output=FILE、指定大空间路径，并用grep -iE "(create|alter|drop|rename|truncate).*table"提取DDL。
通用查询日志能记录CREATE/ALTER/DROP吗
能，但默认不开启，且记录粒度是“所有语句”，不是专为DDL设计的审计日志。它会把SELECT、INSERT甚至连接信息全写进去，容易撑爆磁盘，也难过滤。
实操建议：
- 只在临时排查或低流量环境开启，生产库长期开风险高
- 必须配合
log_output = FILE（不能用TABLE，因为通用日志不支持写入mysql.general_log表） -
general_log_file路径要选在有足够空间的挂载点，比如/var/log/mysql/general.log - 开启后立刻用
tail -f观察输出，确认ALTER TABLE t1 ADD COLUMN x INT这类语句确实被记录
如何从通用日志里快速提取DDL变更
通用日志是纯文本，没有结构化字段，靠grep硬匹配最直接，但要注意大小写和空格干扰。
常见错误现象：用grep "create"漏掉CREATE TABLE（首字母大写），或匹配到CREATE USER这种非DDL操作。
实操建议：
- 用
grep -iE "(create|alter|drop|rename|truncate).*table"限定目标对象类型 - 加
awk '{print $1,$2,$4,$5}'提取时间戳+用户+语句前段，避免整行日志太长 - 如果日志量大，先
zcat general.log.*.gz | ...处理压缩归档，别只查当前文件 - 注意MySQL 8.0+日志格式多了线程ID和客户端IP，
$3可能是[Note]或[Warning]，别误当用户名
general_log开启后性能掉多少
不是“慢一点”，而是I/O瓶颈型下降：每条语句都触发一次磁盘写，QPS过500时fsync可能拖垮吞吐，尤其机械盘或云盘IOPS受限时。
使用场景：仅限小时级临时开启，比如上线前确认某次ALTER TABLE是否执行成功，或回溯某张表何时被删。
实操建议：
- 绝对不要在主库长期开启；从库也慎用，可能影响复制延迟
- 用
SET GLOBAL general_log = 'OFF'关闭后，记得检查ps aux | grep mysqld确认无残留写入进程 - 如果只是想盯DDL，优先考虑
performance_schema.events_statements_history_long（需consumers启用），它内存中缓存最近10000条，无磁盘开销
为什么不用binlog代替通用日志审计DDL
binlog确实记录了所有DDL，但它存的是二进制事件，不是可读SQL；而且binlog_format = ROW时，CREATE TABLE这类语句根本不会进入binlog（只记录DML）。
参数差异关键点：
-
binlog_format = STATEMENT才记录完整DDL文本，但该模式在MySQL 8.0.30+已标记为deprecated -
binlog_row_image = FULL对DDL无效，它只影响UPDATE/DELETE的行镜像 - 解析binlog需用
mysqlbinlog --base64-output=DECODE-ROWS -v，输出仍含大量元数据，不如grep通用日志直观
真正可靠的DDL审计得靠企业版audit_log插件，或Percona Server的query_response_time扩展——通用日志只是权宜之计，别把它当长期方案。
