2023-06-26 22:17左右，收到某系统的主库磁盘使用率告警。2023-06-26 23:02左右收到该系统的从库磁盘使用率告警。

收到告警后，登录数据库查看各表的磁盘使用。

经分析发现DB存在一个当日的备份表t_eap_sys_navigation_log_bak_20230626 ，且在OS层面存在 命名异常的表文件（#开头），按照经验推断#开头为中间表，磁盘使用率告警恢复后，该中间表也不存在了。

通过proxysql中间件获取t_eap_sys_navigation_log_bak_20230626的操作记录，该表的确存在   OPTIMIZE table  与 ANALYZE table 行为。

真相大白，经核实，有同事对t_eap_sys_navigation_log实施 rename -> ANALYZE -> OPTIMIZE 操作。 OPTIMIZE table 会 recreate + analyze table，而 recreate 18G大表会产生 18G的中间表，造成了磁盘使用率的急剧上升， recreate 完成后 同步到从库且 会清理中间表，磁盘使用率恢复正常。

MySQL 中 optimize table、analyze table 和 alter table engine 的区别

• alter table t engine = InnoDB（也就是 recreate）

• analyze table t 不是重建表，只是对表的索引信息做重新统计，没有修改数据，这个过程中加了 MDL 读锁；

• optimize table t 等于 recreate + analyze。

• optimize table、analyze table 和 alter table engine 都会由主库同步到从库，需要注意大表recreate的磁盘空间消耗，主从延迟等影响