碎片率超20%且为慢查询高频表才需排查，优先analyze table而非重建；重建前须确认磁盘空间充足、无长事务、innodb_file_per_table=on，并重建后执行analyze table。
查INFORMATION_SCHEMA.TABLES确认碎片率是否真超标
别光看Data_free绝对值大就动手，它只是粗略参考。真正要算的是碎片率：Data_free / (Data_length + Index_length)。超过 0.2（即 20%）才值得继续排查。
执行这句：
SELECT TABLE_NAME, ROUND(Data_free / (Data_length + Index_length), 2) AS frag_ratio FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'your_db' AND ENGINE = 'InnoDB' AND Data_length > 0 ORDER BY frag_ratio DESC LIMIT 5;
-
Data_free高但frag_ratio - 结果里
frag_ratio> 0.25，且该表恰好是慢查询高频访问对象，才进入下一步 - 注意：如果
innodb_file_per_table = OFF，Data_free不代表可释放空间，这个比值直接失效
用EXPLAIN验证碎片是否影响了执行计划
碎片本身不卡点查（比如WHERE id = ?），但它会让优化器误判——因为avg_row_length失真，导致本该走索引的 SQL 被强制全表扫描。
重点看两个信号：
-
rows远大于filtered * rows（例如rows=120000但filtered=1.5），说明页内空洞多、实际扫描行数虚高 - 频繁出现
Using temporary; Using filesort，且没走覆盖索引，大概率是碎片导致临时表膨胀、排序缓存命中率下降 - 同一 SQL 在不同时间
EXPLAIN的rows波动剧烈（从几百跳到几十万），但表总行数没变，就是统计失真典型表现
检查INFORMATION_SCHEMA.INNODB_TABLESTATS是否失真
升级后或长期未 ANALYZE 的表，INNODB_TABLESTATS里的avg_row_length和n_rows可能严重偏离真实值，这才是拖慢查询的根因，不是物理碎片本身。
运行：
SELECT table_name, n_rows, avg_row_length FROM INFORMATION_SCHEMA.INNODB_TABLESTATS WHERE table_name = 't' AND database_name = 'your_db';
- 拿
avg_row_length乘以n_rows，和SHOW TABLE STATUS LIKE 't'里的Data_length对比：偏差超 2 倍？说明统计崩了 - 再手动估算单行真实字节数（所有字段长度加起来），如果
avg_row_length比它大 3 倍以上，基本可以断定优化器被误导 - 这时优先跑
ANALYZE TABLE t，而不是直接重建表——有时只是统计不准，不是真有碎片
执行重建前必须人工核对的三件事
很多ALTER TABLE ... ENGINE=InnoDB卡住或失败，就因为这三步跳过了：
- 磁盘剩余空间 ≥
Data_length + Index_length（查SHOW TABLE STATUS LIKE 't'），不是“差不多”，是必须够——重建会先写新.ibd文件 - 确认无长事务：
SELECT * FROM information_schema.INNODB_TRX WHERE trx_started，有结果就得等它结束，否则 DDL 会被阻塞 -
SHOW VARIABLES LIKE 'innodb_file_per_table'必须返回ON；若为OFF，重建无法把空间还给操作系统，只会内部复用
碎片清理不是“一键加速”，而是权衡锁、空间、统计信息的一次精准干预。最容易被忽略的是：重建后若没触发ANALYZE TABLE，优化器可能继续用旧统计，反而更慢。
