14.10.4 Defragmenting a Table 整理表: 随机插入或者删除从一个secondary index 可以导致index变的fragmented Fragmentation意味着index pages 物理的顺序在磁盘上不是接近于索引的记录 或者这里有很多的没有使用的pages 在64-page blocks 分配给index. 碎片的征兆是一个表占用了更多的空间,相比它本该占用。 到底是多少, 很难确定。 所有的InnoDB data 和indexes 是存储在B-trees, 它们的填充因子可能从 50% to 100%. 另外一个征兆是 一个表扫描比如它花费更多的时间 相比它该做的。 SELECT COUNT(*) FROM t WHERE non_indexed_column <> 12345; 前面的查询需要执行一个全表扫描,对于大表查询最慢的一种类型 为了加速索引扫描,你可以周期性的执行一个null ALTER TABLE operation, 让mysql 重建表 ALTER TABLE tbl_name ENGINE=INNODB 在Mysql 5.6.3,你可以使用ALTER TABLE tbl_name FORCE 执行一个null alter 操作 来重建表, 先前的FORCE 选项被确认但是忽略 另外一种方式执行一个defragmentation整理操作是用mysqldump 来dump 表到一个文件, drop table 和从dump 文件加载 如果插入到一个index 总是上升的,记录被删除总是从end, InnoDB filespace 管理算法保证了碎片在索引不发生。