如何查看MySQL中OPTIMIZE TABLE语句的执行历史？

核心结论 #

MySQL默认不会自动记录OPTIMIZE TABLE或ANALYZE TABLE的执行历史，必须依赖日志、审计工具或间接判断手段。你提到的利用临时表替换原表的特性无法精准追踪执行历史，原因会在下文说明。

一、可行的直接追踪方法 #

1. 慢查询日志（若已开启并配置） #

如果慢查询日志包含DDL语句（需确保long_query_time设置足够小，或通过log_output配置记录DDL），可以直接搜索日志内容定位目标操作：

# 搜索日志中的OPTIMIZE/ANALYZE语句
grep -E "OPTIMIZE TABLE|ANALYZE TABLE" /var/log/mysql/mysql-slow.log

日志中会包含执行时间、执行用户及目标表名。

2. 通用查询日志（临时/永久开启） #

通用查询日志会记录所有执行的SQL语句，包括DDL操作：

• 临时开启（重启后失效）：

  SET GLOBAL general_log = 1;
  SET GLOBAL general_log_file = '/var/log/mysql/general.log';
  

• 永久开启：在my.cnf/my.ini中添加配置：

  general_log = 1
  general_log_file = '/var/log/mysql/general.log'
  

之后可通过搜索日志找到目标操作，但注意通用日志会占用大量磁盘空间，生产环境需谨慎使用。

3. 审计插件（企业版专属） #

MySQL企业版自带MySQL Enterprise Audit插件，可配置记录DDL操作，能精准追踪执行时间、执行用户及目标表。配置完成后，可直接查询审计日志表或文件获取历史记录。

二、关于利用临时表替换特性追踪的可行性 #

你提到的OPTIMIZE TABLE会创建临时表替换原表的特性，无法用于精准追踪执行历史，原因：

• 执行OPTIMIZE TABLE后，原表的CREATE_TIME会被更新为临时表的创建时间，但这个字段无法区分是OPTIMIZE导致的更新，还是真的新建表的时间——正如你所说，新建表的CREATE_TIME也会是最新值，两者无法区分。
• information_schema.TABLES中没有专门记录OPTIMIZE/ANALYZE执行时间的字段，因此无法通过该表直接获取执行历史。

三、间接判断的替代方案 #

虽然无法直接获取执行历史，但可以通过以下方式间接推测哪些表最近可能被执行过OPTIMIZE：

1. 查看表的UPDATE_TIME（InnoDB适用） #

执行OPTIMIZE TABLE会重建表，因此会更新表的UPDATE_TIME字段。注意：该字段也会在表数据更新时改变，仅作参考：

SELECT table_name, create_time, update_time, 
       ROUND(data_length/1024/1024) AS data_length_mb,
       ROUND(data_free/1024/1024) AS data_free_mb
FROM information_schema.tables 
WHERE table_schema = 'myDB'
ORDER BY update_time DESC;

2. 结合碎片情况与更新时间 #

OPTIMIZE TABLE会大幅减少data_free（碎片空间），可以结合data_free的变化和update_time来推测，但无法100%确定是OPTIMIZE导致的碎片减少（也可能是数据删除后自动整理）。

内容的提问来源于stack exchange，提问作者gouthV_