OPTIMIZE TABLE对InnoDB表仅在真实存在严重碎片、磁盘空间充足、无长事务且innodb_file_per_table=ON时才应执行；否则易锁表、浪费空间或加剧主从延迟。判断真碎片需综合计算data_length/table_rows是否远超业务预期、Data_free持续>100MB且占比超20%、Handler_read_next高且key_len异常偏小。
OPTIMIZE TABLE 不是万能解药，它对 InnoDB 表实际执行的是 ALTER TABLE FORCE 全表重建，只有在真实存在严重碎片、磁盘空间充足、无长事务且 innodb_file_per_table=ON 时才应执行；否则极易锁表数小时、浪费磁盘空间、加剧主从延迟。
怎么确认真有碎片，而不是误判？
别只看 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 ，有就别动，等它结束 - 检查
innodb_file_per_table必须为ON；若为OFF，所有表共用ibdata1，OPTIMIZE TABLE根本无法释放空间给操作系统
替代方案：什么时候该换用 ALTER TABLE ... ENGINE=InnoDB？
语义更明确，效果与 OPTIMIZE TABLE 完全一致，但更适合脚本化或自动化流程中使用。
- 当 DBA 或运维同学需要在监控告警触发后自动执行清理时，
ALTER TABLE t ENGINE=InnoDB比OPTIMIZE TABLE t更易被日志审计识别，也避免某些旧版本 MySQL 对OPTIMIZE的歧义解析 - 若你已在用
pt-online-schema-change管理 DDL，可直接套用：pt-online-schema-change --alter="ENGINE=InnoDB" D=db,t=t --execute，实现真正零锁表 - 注意：MySQL 8.0+ 支持
ALGORITHM=INPLACE, LOCK=NONE的在线重建，但仅适用于部分场景；对大表仍建议用pt-osc或分批INSERT ... SELECT+ 重命名法，尤其是涉及主从延迟敏感的系统
真正容易被忽略的是：碎片只是表层症状。一次 OPTIMIZE TABLE 执行完，如果没同步检查 innodb_buffer_pool_size 是否匹配当前数据规模、没确认慢查询是否还在用 SELECT *、也没验证从库是否已追平，那所谓的“优化”可能只是把问题从磁盘搬到了内存或复制链路上。
