Mysql InnoDB 爲啥選擇B+樹索引

前言

Mysql數據庫中的常見索引有多種方式，例如Hash索引，B-樹索引，B+樹索引，可是爲啥mysql中默認是採用B+樹索引索引呢？下面對這三種索引學習總結一下。B+樹到底有啥優點？
B-樹

B-樹,這裏的 B 表示 balance( 平衡的意思),B-樹是一種多路自平衡的搜索樹(不是二叉樹)。它相似普通的平衡二叉樹，不一樣的一點是B-樹容許每一個節點有更多的子節點。下圖是 B-樹的簡化圖。

B-樹有以下特色:

    全部鍵值分佈在整顆樹中；

    任何一個關鍵字出現且只出如今一個結點中；

    搜索有可能在非葉子結點結束；

    在關鍵字全集內作一次查找,性能逼近二分查找；

 B+ 樹

B+樹是爲磁盤及其餘存儲輔助設備而設計一種平衡查找樹（不是二叉樹）。B+樹中，全部記錄的節點按大小順序存放在同一層的葉節點中，各葉節點用指針進行鏈接。B+樹從根節點到葉子節點的搜索效率基本至關，不會出現大幅波動。

簡化 B+樹 以下圖

B+樹有以下特色

    B+樹每一個節點能夠包含更多的節點，這樣作有兩個緣由,一個是下降樹的高度。另一個是將數據範圍變爲多個區間，區間越多，數據檢索越快。佔用空間很是小，所以每一層的節點能索引到的數據範圍更加的廣。換句話說，每次IO操做能夠搜索更多的數據。
    每一個節點再也不只是存儲一個key了，能夠存儲多個key。

    非葉子節點存儲key，葉子節點存儲key和數據。

    葉子節點兩兩指針相互連接，順序查詢性能更高。葉子節點兩兩相連，符合磁盤的預讀特性。好比葉子節點存儲50和55，它有個指針指向了60和62這個葉子節點，那麼當咱們從磁盤讀取50和55對應的數據的時候，因爲磁盤的預讀特性，會順便把60和62對應的數據讀取出來。這個時候屬於順序讀取，而不是磁盤尋道了，加快了速度。

哈希索引

哈希索引就是採用必定的哈希算法，把鍵值換算成新的哈希值，檢索時不須要相似B+樹那樣從根節點到葉子節點逐級查找，只需一次哈希算法便可馬上定位到相應的位置，速度很是快。

 

從上面的圖來看，B+樹索引和哈希索引的明顯區別是：

    若是是等值查詢，那麼哈希索引明顯有絕對優點，由於只須要通過一次算法便可找到相應的鍵值；固然了，這個前提是，鍵值都是惟一的。若是鍵值不是惟一的，就須要先找到該鍵所在位置，而後再根據鏈表日後掃描，直到找到相應的數據；

    若是是範圍查詢檢索，這時候哈希索引就毫無用武之地了，由於原先是有序的鍵值，通過哈希算法後，有可能變成不連續的了，就沒辦法再利用索引完成範圍查詢檢索；

    哈希索引也沒辦法利用索引完成排序，以及like ‘xxx%’ 這樣的部分模糊查詢（這種部分模糊查詢，其實本質上也是範圍查詢）；

    哈希索引也不支持多列聯合索引的最左匹配規則；

    B+樹索引的關鍵字檢索效率比較平均，不像B樹那樣波動幅度大，在有大量重複鍵值狀況下，哈希索引的效率也是極低的，由於存在所謂的哈希碰撞問題。

總結

上面大體介紹了B-樹，B+樹，哈希索引。那麼B+樹的優點大體總結以下

    不一樣於B-樹只適合隨機檢索，B+樹同時支持隨機檢索和順序檢索；
    B+樹的磁盤讀寫代價更低。B+樹內部結點比B-樹小，盤塊能容納的結點中關鍵字數量更多，一次性讀入內存中能夠查找的關鍵字也就越多，相對的，IO讀寫次數也就下降了。而IO讀寫次數是影響索引檢索效率的最大因素。
    B+樹的查詢效率更加穩定。B-樹搜索有可能會在非葉子結點結束，越靠近根節點的記錄查找時間越短，只要找到關鍵字便可肯定記錄的存在，其性能等價於在關鍵字全集內作一次二分查找。而在B+樹中，順序檢索比較明顯，隨機檢索時，任何關鍵字的查找都必須走一條從根節點到葉節點的路，全部關鍵字的查找路徑長度相同，致使每個關鍵字的查詢效率至關。
    B-樹在提升了磁盤IO性能的同時並無解決元素遍歷的效率低下的問題。B+樹的葉子節點使用指針順序鏈接在一塊兒，只要遍歷葉子節點就能夠實現整棵樹的遍歷。並且在數據庫中基於範圍的查詢是很是頻繁的，而B-樹不支持這樣的操做（或者說效率過低）。

參考文獻

1.https://blog.csdn.net/m0_37947204/article/details/81046943

2.https://segmentfault.com/a/1190000004690721

3.https://blog.csdn.net/mine_song/article/details/63251546

4.http://www.cnblogs.com/zengkefu/p/5647279.html