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 管理算法保证了碎片在索引不发生。
14.10.4 Defragmenting a Table 整理表的相关教程结束。
