14.9.4 Defragmenting a Table 整理表

14.9.4 Defragmenting a Table   整理表

随机的插入或者从一个 secondary index 删除会导致index变的 破碎。


碎片意味着 index pages物理的顺序在磁盘上和记录在pages里的index 顺序不接近,


或者有很多的没有使用的Pgaes 在64-page blocks 分配给索引


碎片化的征兆是 一个表占据更多的空间 相比它应该占用的大小, 究竟是多少,


是很难确定的。所有的InnoDB 数据和Indexes 是存储在B-trees，它们的填充因子可能从50%到100%


另外一个碎片的征兆是一个表扫描 花费更长的时间。


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


前面的查询需要MySQL 执行一个全表扫描, 对于一个大表最慢的查询方式


为了加快所有扫描,你可以周期性的执行一个 "null" ALTET TABLE操作,

会让MySQL 重建表:

ALTER TABLE tbl_name ENGINE=INNODB


在MySQL 5.6.3,你可以使用 ALTER TABLE tbl_name FORCE来执行一个"null" alter 操作来重建表,

先前的FORCE 选项是有效的但是可以忽略


在MySQL 5.6.17，ALTER TABLE  tbl_name ENGINE=INNODB 和 ALTER TABLE  tbl_name FORCE 


使用online DDL（ALGORITHM=COPY).


另一种方式执行一个碎片操作是使用mysqldump 来dump 表到文件,删除表,重新从备份加载。




如果插入到一个index总是向上的 记录总是在最后端删除,InnoDB 文件管理算法强制 碎片在索引上不发生。