OPTIMIZE TABLE对InnoDB表多数时候“没效果”是因为未满足前提条件：innodb_file_per_table必须为ON，DATA_FREE需真实偏高（>100MB且占比>20%），且无长事务阻塞；否则无法触发空间回收。
OPTIMIZE TABLE 对 InnoDB 表多数时候“没效果”，不是命令写错了，而是它根本没触发空间回收——关键看 innodb_file_per_table 是否为 ON、DATA_FREE 是否真实偏高、有没有长事务卡着。
怎么确认表真有碎片，而不是误判？
别信“删了 50% 数据肯定有碎片”这种感觉。真正可依赖的只有 DATA_FREE 字段，但它只在 innodb_file_per_table = ON 时有意义。
- 查单表：执行
SHOW TABLE STATUS LIKE 'your_table';，看Data_free值（单位字节）；持续 > 100MB 且占Data_length + Index_length超过 20% 才算严重 - 批量筛查：用这个 SQL 找出最急需处理的表：
SELECT CONCAT(table_schema,'.',table_name) AS tbl, sys.FORMAT_BYTES(data_free) AS free, ROUND((data_free / (data_length + index_length)) * 100, 2) AS pct FROM information_schema.tables WHERE engine = 'InnoDB' AND data_free > 100*1024*1024 ORDER BY data_free DESC LIMIT 10;
-
table_rows和avg_row_length是采样估算值，不能用来反推碎片率；DATA_FREE = 0不代表无碎片（比如页内碎片），但它是唯一能被OPTIMIZE TABLE实际回收的部分
为什么 OPTIMIZE TABLE 执行完 .ibd 文件大小不变？
这是最常遇到的“失效”现象，本质是条件不满足，不是命令本身有问题。
-
innodb_file_per_table关闭了：执行SELECT @@innodb_file_per_table;，返回0就说明所有表共用ibdata1，OPTIMIZE TABLE根本无法把空间还给操作系统 - 表上有未提交的长事务：
OPTIMIZE会卡在Waiting for table flush状态，SHOW PROCESSLIST;能看到；必须 kill 或等它结束 - 磁盘临时空间不足：重建过程需要额外空间 ≥ 当前
.ibd大小；若只剩 20GB，而表文件 25GB，命令会失败或假死 - 用了压缩表（
ROW_FORMAT=COMPRESSED）：MySQL 5.7 某些小版本会静默跳过，不报错也不生效
ALTER TABLE ENGINE=InnoDB 比 OPTIMIZE TABLE 更可控
它和 OPTIMIZE TABLE 在 InnoDB 下行为一致（都是重建表），但语义更清晰、协作更安全，且更容易配合在线 DDL 控制锁级别。
- 基础写法：
ALTER TABLE your_table ENGINE=InnoDB;—— 效果等同于OPTIMIZE TABLE，但不会被误读为“只是分析统计” - 想降低业务影响（MySQL 8.0+）：
ALTER TABLE your_table ENGINE=InnoDB, ALGORITHM=INPLACE, LOCK=NONE;—— 注意：这不保证 100% 无锁，需满足无全文索引、无虚拟列等前提 - 检查是否支持：
SHOW CREATE TABLE your_table;看建表语句；再查information_schema.INNODB_TABLES中的FILE_FORMAT，必须是Barracuda（Antelope格式不支持部分在线操作）
大表碎片整理时最易被忽略的三个点
不是“能不能做”，而是“怎么做才不翻车”。很多故障都出在执行前没验证这几个细节。
-
tmpdir空间是否充足：OPTIMIZE或ALTER TABLE重建期间会大量使用临时目录，df -h /tmp必须留足余量，否则中途失败且可能残留临时文件 -
innodb_fast_shutdown应设为0：否则关闭时 purge 线程不彻底，可能导致重建后DATA_FREE仍偏高 - 主从延迟风险：重建大表会生成巨量 binlog，主库写入压力激增，从库容易追不上；建议在低峰期执行，并提前观察
Seconds_Behind_Master
