14.10.4 Defragmenting a Table 整理表

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 整理表

最新文章

热门文章
