向辅助索引中随机插入或删除数据可能会导致索引碎片化。碎片化意味着磁盘上索引页的物理顺序与页面上记录的索引顺序不接近，或者分配给索引的 64 页块中有许多未使用的页面。

碎片化的一个症状是表占用的空间比其“应该”占用的空间多。确切地说，这很难确定。所有 InnoDB 数据和索引都存储在 B 树中，它们的 填充因子可能在 50% 到 100% 之间变化。碎片化的另一个症状是，像这样的表扫描比其“应该”花费的时间要长

SELECT COUNT(*) FROM t WHERE non_indexed_column <> 12345;

前面的查询要求 MySQL 执行全表扫描，这是大型表中最慢的查询类型。

为了加快索引扫描速度，您可以定期执行“null” ALTER TABLE 操作，这将导致 MySQL 重建表

ALTER TABLE tbl_name ENGINE=INNODB

您还可以使用 ALTER TABLE tbl_name FORCE 执行重建表的“null” alter 操作。

ALTER TABLE tbl_name ENGINE=INNODB 和 ALTER TABLE tbl_name FORCE 都使用 在线 DDL。有关更多信息，请参见 第 17.12 节，“InnoDB 和在线 DDL”。

执行碎片整理操作的另一种方法是使用 mysqldump 将表转储到文本文件，删除该表，然后从转储文件重新加载它。

如果插入到索引中的数据始终是升序的，并且仅从末尾删除记录，则 InnoDB 文件空间管理算法可以保证索引中不会出现碎片。