索引是幫助mysql獲取數據的數據結構。最常見的索引是Btree索引和Hash索引。

不同的引擎對于索引有不同的支持：Innodb和MyISAM默認的索引是Btree索引；而Mermory默認的索引是Hash索引。

Hash索引

所謂Hash索引，當我們要給某張表某列增加索引時，將這張表的這一列進行哈希算法計算，得到哈希值，排序在哈希數組上。所以Hash索引可以一次定位，其效率很高，而Btree索引需要經過多次的磁盤IO，但是innodb和myisam之所以沒有采用它，是因為它存在著好多缺點：

1、因為Hash索引比較的是經過Hash計算的值，所以只能進行等式比較，不能用于范圍查詢

1、每次都要全表掃描

2、由于哈希值是按照順序排列的，但是哈希值映射的真正數據在哈希表中就不一定按照順序排列，所以無法利用Hash索引來加速任何排序操作

3、不能用部分索引鍵來搜索，因為組合索引在計算哈希值的時候是一起計算的。

4、當哈希值大量重復且數據量非常大時，其檢索效率并沒有Btree索引高的。

?

Btree索引

至于Btree索引，它是以B+樹為存儲結構實現的。

但是Btree索引的存儲結構在Innodb和MyISAM中有很大區別。

在MyISAM中，我們如果要對某張表的某列建立Btree索引的話，如圖：

?

?

所以我們經常會說MyISAM中數據文件和索引文件是分開的。

因此MyISAM的索引方式也稱為非聚集，Innodb的索引方式成為聚集索引。

至于輔助索引，類似于主索引，唯一區別就是主索引上的值不能重復，而輔助索引可以重復。

?

?

?

因此當我們根據Btree索引去搜索的時候，若key存在，在data域找到其地址，然后根據地址去表中查找數據記錄。

至于Innodb它跟上面又有很大不同，它的葉子節點存儲的并不是表的地址，而是數據

?

?

?

?

我們可以看到這里并沒有將地址放入葉子節點，而是直接放入了對應的數據，這也就是我們平常說到的，Innodb的索引文件就是數據文件，

?

那么對于Innodb的輔助索引結構跟主索引也相差很多，如圖：

?

?

?

我們可以發現，這里葉子節點存儲的是主鍵的信息，所以我們在利用輔助索引的時候，檢索到主鍵信息，然后再通過主鍵去主索引中定位表中的數據，這就可以說明Innodb中主鍵之所以不宜用過長的字段，由于所有的輔助索引都包含主索引，所以很容易讓輔助索引變得龐大。

?

?

我們還可以發現：在Innodb中盡量使用自增的主鍵，這樣每次增加數據時只需要在后面添加即可，非單調的主鍵在插入時會需要維持B+tree特性而進行分裂調整，十分低效。

?

?

Btree索引中的最左匹配原則：

Btree是按照從左到右的順序來建立搜索樹的。比如索引是(name,age,sex)，會先檢查name字段，如果name字段相同再去檢查后兩個字段。

所以當傳進來的是后兩個字段的數據（age，sex），因為建立搜索樹的時候是按照第一個字段建立的，所以必須根據name字段才能知道下一個字段去哪里查詢。

所以傳進來的是（name，sex）時，首先會根據name指定搜索方向，但是第二個字段缺失，所以將name字段正確的都找到后，然后才會去匹配sex的數據。

?

?

建立索引的規則：

1、利用最左前綴：Mysql會一直向右查找直到遇到范圍操作（>，<，like、between）就停止匹配。比如a=1?and?b=2?and?c>3?and?d=6；此時如果建立了（a,b,c,d）索引，那么后面的d索引是完全沒有用到，當換成了（a,b,d,c）就可以用到。

2、不能過度索引：在修改表內容的時候，索引必須更新或者重構，所以索引過多時，會消耗更多的時間。

3、盡量擴展索引而不要新建索引

4、最適合的索引的列是出現在where子句中的列或連接子句中指定的列。

5、不同值較少的列不必要建立索引（性別）。

?

原文鏈接：http://blog.csdn.net/u014307117/article/details/47325091

轉載于:https://www.cnblogs.com/yiweiyihang/p/8340351.html

總結

以上是生活随笔為你收集整理的Hash索引和BTree索引的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。