判断表是否存在索引碎片需查information_schema.tables中data_free字段，frag_pct＞20%或data_free＞100mb为整理阈值；optimize table对innodb实为重建表并更新统计信息，期间加读锁；大表建议用pt-online-schema-change在线处理。
怎么判断表真有索引碎片？别光看 OPTIMIZE TABLE 提示
MySQL 不会主动告诉你“这个表碎片严重”，得自己查。核心指标是 information_schema.tables 里的 data_free 字段——它代表物理上被标记为“空”但还没被回收的字节数，也就是最典型的页级空洞。
- 执行这条查询就能筛出可疑表：
SELECT table_name, data_length, index_length, data_free, ROUND((data_free / NULLIF(data_length + index_length, 0)) * 100, 2) AS frag_pct FROM information_schema.tables WHERE table_schema = 'your_db' AND data_free > 0;
- 碎片率
frag_pct > 20%是动手整理的常见阈值；超过 50% 或data_free > 100MB就该优先处理 -
data_free = 0不等于没碎片——比如页内记录稀疏（页填充率低）、B+ 树节点分裂后未合并，这些data_free看不见，但会影响顺序扫描性能
OPTIMIZE TABLE 到底干了啥？InnoDB 和 MyISAM 完全不是一回事
对 MyISAM，OPTIMIZE TABLE 是原生命令：重建 .MYD/.MYI 文件、压缩行、重排索引。对 InnoDB，它本质就是 ALTER TABLE ... ENGINE=InnoDB 的语法糖，触发全表重建 + ANALYZE TABLE 更新统计信息。
- 期间 InnoDB 表加的是**读锁**（可查不可写），不是完全不可用，但写入请求会排队等待
- 大表（比如 >10GB）执行时间取决于数据量，和文件大小无关；一次跑完可能耗几十分钟，线上务必避开高峰
- 如果表原本就是 InnoDB，执行
OPTIMIZE TABLE t和ALTER TABLE t ENGINE=InnoDB效果一致，后者更显式、兼容性更好 - 不推荐在主从架构里频繁用——默认会写 binlog，从库也得重放一遍重建过程；加
NO_WRITE_TO_BINLOG可跳过（但要确保从库状态可控）
大表不敢锁？换 pt-online-schema-change 在线整理
当 OPTIMIZE TABLE 的锁和资源开销无法接受时，就得靠 Percona Toolkit 的 pt-online-schema-change——它通过创建影子表、触发器同步增量、原子切换的方式，实现“零停机”重建。
- 命令形如：
pt-online-schema-change --alter "ENGINE=InnoDB" D=your_db,t=your_table --execute
- 它不依赖 MySQL 原生 DDL 锁机制，但要求表必须有主键或唯一非空索引（否则无法可靠同步）
- 会额外消耗磁盘空间（影子表 + 日志），建议预留 ≥ 原表 2 倍空间
- 运行中若中断，工具能自动清理临时对象；但手动删掉中间表或触发器会导致数据不一致，千万别手欠
什么情况其实不用急着 OPTIMIZE？小心越整越慢
碎片不是万恶之源，盲目优化反而伤性能。关键看业务特征和瓶颈是否真在 I/O 寻道上。
- 高写低查的日志类表（比如
event_log）：碎片对查询影响小，但OPTIMIZE本身会引发大量随机写，加重 I/O 压力 - 用 UUID 或雪花 ID 当主键的表：每次插入都在 B+ 树不同位置分裂页，碎片是持续发生的；定期
OPTIMIZE治标不治本，重构为主键加时间前缀或改用自增才是根因解法 - 只读归档表或分区表的老分区：可直接
TRUNCATE PARTITION或DROP PARTITION，比OPTIMIZE快得多也干净得多
真正容易被忽略的是：碎片问题往往和慢查询共存，但先查执行计划、确认是不是走了索引、统计信息是否过期，比直接 OPTIMIZE 更有效。有时候一个 ANALYZE TABLE 就够了。
