innodb主键碎片即表碎片本身，源于聚簇索引页的空洞、页分裂残留和物理不连续；需通过optimize table或alter table engine=innodb重建整表来清理，且须确保innodb_file_per_table=on、磁盘空间充足、无长事务。
主键碎片不是独立存在，它就是表碎片本身
InnoDB 的主键即聚簇索引，数据行就存在这棵树的叶子节点里。所谓“主键碎片”，本质是聚簇索引页（ibd 文件内）的空洞、页分裂残留和物理不连续——它不会单独出现在某个字段上，而是整张表存储结构的问题。查 information_schema.TABLES 里的 DATA_FREE 值只是粗略参考，真正影响查询的是页利用率和逻辑顺序性。比如 DATA_FREE 显示 50MB，但若这些空洞分散在成千上万个页里，随机 I/O 开销会远高于连续读取。
确认碎片是否真在拖慢查询
别一慢就 opt，先排除干扰：
- 用
EXPLAIN看执行计划是否走错索引、是否回表严重——SELECT *配合大TEXT字段时，即使碎片清零，首次缓存未热也会慢 - 查
innodb_buffer_pool_size是否足够：如果总数据量 100GB，而缓冲池只设了 4GB，那每次OPTIMIZE TABLE后都要冷加载，首条查询必然卡顿 - 运行
SELECT TABLE_NAME, ROUND(DATA_FREE / DATA_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;，碎片率 > 0.2 才值得动
重建聚簇索引必须用 ENGINE=InnoDB，不是 DROP INDEX
单独 DROP INDEX 或 ALTER TABLE ... ADD INDEX 只动二级索引，完全不碰主键页里的空洞。真正清理主键碎片，只有重建整张表这一条路：
-
OPTIMIZE TABLE t;—— 语义清晰，但部分云厂商（如阿里云 RDS）会禁用该命令 -
ALTER TABLE t ENGINE=InnoDB;—— 效果等同，兼容性更好，推荐优先用 - MySQL 8.0+ 想减少锁时间？加
ALGORITHM=INPLACE, LOCK=NONE，但注意：这仅适用于某些 DDL 场景，ENGINE=InnoDB在 8.0 中默认仍走 copy 算法，ALGORITHM=INPLACE对它无效 - 务必确保
innodb_file_per_table = ON，否则OPTIMIZE或ALTER ENGINE根本无法把空间还给操作系统，只会内部复用
执行前必须检查三件事，缺一不可
很多 OPTIMIZE 卡住或失败，根源都在这三步没做：
- 磁盘剩余空间 ≥ 当前
t.ibd文件大小（不是DATA_LENGTH）——重建过程会先写新.ibd，再原子替换，临时需要双倍空间 - 无长事务：跑
SELECT * FROM information_schema.INNODB_TRX WHERE trx_started ，有结果就得等它结束，否则 DDL 会被阻塞 - 避开主从复制高峰：
OPTIMIZE TABLE会产生一个巨型ALTER TABLE ... FORCEbinlog，从库可能追不上，尤其当表超大时
碎片整理后查询没变快？大概率是缓冲池还没预热，或者根本不是碎片问题——主键设计（比如用 UUID）导致的页分裂，比碎片更难治，得从写入源头改起。
