B-Tree索引可能會碎片化,這會降低查詢效率.碎片化的索引可能會以很差或者無序的方式存儲在磁盤上 根據設計B-Tree需要隨機磁盤訪問才能定位到葉子頁,所以隨機訪問是不可避免的.然而,如果葉子頁在物理分布上是順序且緊密的,那么查詢性能就會更好.否則,對于范圍查詢,索引覆蓋掃描等操作來說,速度可能會降低很多倍,對于索引覆蓋掃描這一點更加明顯 表的數據存儲也可能碎片化.然而,數據存儲的碎片化比索引更加復雜.有三種類型的數據碎片 * 行碎片 這種碎片指的是數據被存儲為多個地方的多個片段中.即使查詢只從索引中訪問一行記錄,行碎片也會導致性能下降 * 行間碎片 行間碎片是值邏輯上順序的頁,或者行在磁盤上不是順序存儲的.行間碎片對諸如全表掃描和聚簇索引掃描之類的操作有很大的影響,因為這些操作原本能夠從磁盤上順序存儲的數據中獲益 * 剩余空間碎片 剩余空間碎片是指數據頁中有大量的空余空間,這會導致服務器讀取大量大需要的數據,從而造成浪費 對于myisam表,這三類碎片化都可能發生.但Innodb不會出現短小的行碎片,innodb會移動短小的行并重寫到一個片段中 可以通過執行OPTIMIZE TABLE或者導出再導入的方式來重新整理數據,這對多數存儲引擎都是有效的.對于一些存儲引擎如myisam,可以通過排序算法重建索引的方式來消除水平.老版本的Innodb沒有什么消除碎片化的方法.不過最新版本Innodb新增了"在線"添加和刪除索引的功能,可以通過先刪除,然后再重新創建索引的方式來消除索引的碎片化 對于那些不支持OPTIMIZE TABLE的存儲引擎,可以通過一個不做任何操作的ALTER TABLE操作來重建表.只需要將表的存儲引擎改為當前的引擎即可: ~~~ mysql> ALTER TABLE <table> ENGINE=<engine>; ~~~ 對于開啟了`expand_fast_index_creation` 參數的Percona Server,按這種方式重建表,則會同時消除表和索引的碎片化.但對于標準版本的mysql則只會消除表(實際上是聚簇索引)的碎片化.可用先刪除所有索引,然后重建表,最后重新創建索引的方式模擬Percona Server的這個功能