OPTIMIZE TABLE对InnoDB表实际执行全表重建（等价于ALTER TABLE ... FORCE），仅在真实存在严重碎片、磁盘空间充足、无长事务且innodb_file_per_table=ON时才应执行；否则易导致锁表、空间浪费或主从延迟。
OPTIMIZE TABLE 对 InnoDB 表不会“原地整理”碎片，它实际执行的是 ALTER TABLE ... FORCE —— 全表重建。所以它能解决查询变慢，但前提是：你真有碎片，且重建条件满足；否则就是白等、白锁、白占磁盘空间。
怎么判断是不是真该跑 OPTIMIZE TABLE
别光看 Data_free 数值大就动手。这个字段是 InnoDB 估算值，经常虚高或滞后。
- 先查真实行数和平均行长：
SELECT table_rows, avg_row_length, data_length FROM information_schema.TABLES WHERE table_name = 't' AND table_schema = 'db';，算出data_length / table_rows，如果远超业务预期（比如订单表每行应占 1–2KB，结果算出来是 12KB），再结合历史data_length增长曲线确认是否异常膨胀 -
SHOW TABLE STATUS LIKE 't'中的Data_free持续 > 100MB 且占Data_length超过 20%，才值得干预 - 慢查询里频繁出现
Handler_read_next高 +key_len明显小于索引定义长度（比如定义了INDEX idx(a,b)，但EXPLAIN显示key_len=5），说明二级索引页稀疏，碎片已影响索引效率
为什么 OPTIMIZE TABLE 跑完查询还是慢
常见错觉：碎片一清，性能立升。现实往往不是这样。
- 重建后首次查询慢，大概率是
innodb_buffer_pool_size太小，缓存全冷，得等数据重新加载进内存 —— 查SHOW ENGINE INNODB STATUS的Buffer pool hit rate，低于 99% 就要调大池子 - 用了
SELECT *查含TEXT/BLOB的大字段，即使碎片清了，每次回表仍要读整行，I/O 压力没减 - 碎片清理了，但慢查询根本原因是没走对索引，或者
WHERE条件选择性差，这时候建错索引比碎片更致命 - 主从复制场景下，
OPTIMIZE TABLE生成一个巨型ALTER TABLE ... FORCEbinlog，从库重放卡顿，你以为主库快了，其实从库延迟爆表
执行前必须盯死的三件事
跳过任何一项，轻则失败报错，重则锁表数小时、磁盘写满、主从断裂。
- 磁盘剩余空间 ≥
Data_length + Index_length（用SHOW TABLE STATUS LIKE 't'查），不是“差不多”，是必须够 —— 因为重建过程会先写新.ibd文件，再原子替换 - 确认无长事务：
SELECT * FROM information_schema.INNODB_TRX WHERE trx_started < NOW() - INTERVAL 60 SECOND;，有就别动，等它结束 - 检查
innodb_file_per_table必须为ON；若为OFF，所有表共用ibdata1，OPTIMIZE TABLE根本无法把空间还给操作系统，只会内部复用
替代方案：什么时候不该用 OPTIMIZE TABLE
大表、高可用、不能停写 —— 这时 OPTIMIZE TABLE 就是自找麻烦。
- MySQL 8.0+ 可用：
ALTER TABLE t ENGINE=InnoDB, ALGORITHM=INPLACE, LOCK=NONE;，不锁 DML（但仍需短暂 MDL 锁），不写完整 binlog，但注意：它不释放空间，只重组织聚簇索引 - 只想救单个烂索引？
ALTER TABLE t DROP INDEX idx_a, ADD INDEX idx_a (col);比全表重建快得多，也更可控 - 长期写入稳定的表，可开后台自动整理：
SET GLOBAL innodb_defragment=ON;+ 设置innodb_defragment_frequency，让 InnoDB 自己慢慢合并页 - 实在不敢动线上？用
pt-online-schema-change --alter "ENGINE=InnoDB" --execute，它通过影子表+触发器实现几乎无锁重建
真正难的不是执行命令，而是判断“此刻该不该动”——碎片是症状，不是病因；重建是手段，不是目的。磁盘空间、锁时间、主从延迟、buffer pool 状态，这些细节漏掉一个，优化就变成事故。
