數據庫索引——B+樹索引
索引是一種數據結構，用於幫助我們在大量數據中快速定位到我們想要查找的數據。
索引最形象的比喻就是圖書的目錄了。注意這里的大量，數據量大了索引才顯得有意義
索引在 MySQL 數據庫中分三類：
- B+ 樹索引
- Hash 索引
- 全文索引
B+樹索引
B+樹進化具有的優點：
- 索引節點沒有數據，比較小，能夠完全加載到內存中
- 而且葉子節點之間都是鏈表的結構，所以B+Tree也是可以支持范圍查詢的，而B樹每個節點key和data在一起，則無法區間查找
- B+樹中因為數據都在葉子節點，每次查詢的時間復雜度是穩定的，因此穩定性保證了
為什么MySQL要使用B-Tree（B+Tree）? 有哪些優勢？
一般來說，索引本身也很大，不可能全部存儲在內存中，因此索引往往以索引文件的形式存儲的磁盤上。這樣的話，索引查找過程中就要產生磁盤I/O消耗，相對於內存存取，I/O存取的消耗要高幾個數量級，所以評價一個數據結構作為索引的優劣最重要的指標就是在查找過程中磁盤I/O操作次數的漸進復雜度。換句話說，索引的結構組織要盡量減少查找過程中磁盤I/O的存取次數。下面先介紹內存和磁盤存取原理，然后再結合這些原理分析B-/+Tree作為索引的效率。
（0）先看看數據庫表的存儲結構
MySQL的存儲結構
表存儲結構
單位：表>段>區>頁>行
在數據庫中， 不論讀一行，還是讀多行，都是將這些行所在的頁進行加載。也就是說存儲空間的基本單位是頁。
一個頁就是一棵樹B+樹的節點，數據庫I/O操作的最小單位是頁，與數據庫相關的內容都會存儲在頁的結構里。
B+樹索引結構
- 在一棵B+樹中，每個節點為都是一個頁，每次新建節點的時候，就會申請一個頁空間
- 同一層的節點為之間，通過頁的結構構成了一個雙向鏈表
- 非葉子節點為，包括了多個索引行，每個索引行里存儲索引鍵和指向下一層頁面的指針
- 葉子節點為，存儲了關鍵字和行記錄，在節點內部（也就是頁結構的內部）記錄之間是一個單向的鏈表
B+樹頁節點結構
有以下幾個特點
- 將所有的記錄分成幾個組， 每組會存儲多條記錄，
- 頁目錄存儲的是槽（slot），槽相當於分組記錄的索引，每個槽指針指向了不同組的最后一個記錄
- 我們通過槽定位到組，再查看組中的記錄
頁的主要作用是存儲記錄，在頁中記錄以單鏈表的形式進行存儲。
單鏈表優點是插入、刪除方便，缺點是檢索效率不高，最壞的情況要遍歷鏈表所有的節點。因此頁目錄中提供了二分查找的方式，來提高記錄的檢索效率。
B+樹的檢索過程
我們再來看下B+樹的檢索過程
- 從B+樹的根開始，逐層找到葉子節點。
- 找到葉子節點為對應的數據頁，將數據葉加載到內存中，通過頁目錄的槽采用二分查找的方式先找到一個粗略的記錄分組。
- 在分組中通過鏈表遍歷的方式進行記錄的查找。
（1）B+樹的演變
二叉查找樹（二叉搜索樹）：不平衡
我們為 user 表（用戶信息表）建立了一個二叉查找樹的索引。
圖中的圓為二叉查找樹的節點，節點中存儲了鍵（key）和數據（data）。鍵對應 user 表中的 id，數據對應 user 表中的行數據。
特點：
二叉查找樹的特點就是任何節點的左子節點的鍵值都小於當前節點的鍵值，右子節點的鍵值都大於當前節點的鍵值。頂端的節點我們稱為根節點，沒有子節點的節點我們稱之為葉節點。
示例：
如果我們需要查找 id=12 的用戶信息，利用我們創建的二叉查找樹索引，查找流程如下：
- 將根節點作為當前節點，把 12 與當前節點的鍵值 10 比較，12 大於 10，接下來我們把當前節點>的右子節點作為當前節點。
- 繼續把 12 和當前節點的鍵值 13 比較，發現 12 小於 13，把當前節點的左子節點作為當前節點。
- 把 12 和當前節點的鍵值 12 對比，12 等於 12，滿足條件，我們從當前節點中取出 data，即 id=12，name=xm。
平衡二叉樹（AVL樹）：旋轉耗時
利用二叉查找樹可以快速的找到數據。但是，如果上面的二叉查找樹是下面的構造，則二叉查找樹變成了一個鏈表。如果我們需要查找 id=17 的用戶信息，我們需要查找 7 次，也就相當於全表掃描了。 ——於是我們就有了平衡二叉樹
特點：
平衡二叉樹又稱 AVL 樹，在滿足二叉查找樹特性的基礎上，要求每個節點的左右子樹的高度差不能超過 1。
平衡二叉樹和非平衡二叉樹的對比：
當不平衡時，則需要調整二叉平衡樹的平衡，請參考鏈接：AVL和紅黑樹的一些概念
紅黑樹：樹太高
與AVL樹相比，紅黑樹並不追求嚴格的平衡，而是大致的平衡：只是確保從根到葉子的最長的可能路徑不多於最短的可能路徑的兩倍長。
從實現來看，紅黑樹最大的特點是每個節點都屬於兩種顏色(紅色或黑色)之一，且節點顏色的划分需要滿足特定的規則。
紅黑樹是滿足如下條件的二叉搜索樹：
- 每個結點要么是紅色，要么是黑色
- 根節點是黑色
- 每個葉結點（NIL結點，空結點）是黑色的
- 不能有相鄰的兩個紅色結點
- 從任一結點到其每個葉子的所有路徑都包含相同數目的黑色結點
紅黑樹示例如下：
與AVL樹相比，紅黑樹的查詢效率會有所下降，這是因為樹的平衡性變差，高度更高。
但紅黑樹的刪除效率大大提高了，因為紅黑樹同時引入了顏色，當插入或刪除數據時，只需要進行O(1)次數的旋轉以及變色就能保證基本的平衡，不需要像AVL樹進行O(lgn)次數的旋轉。總的來說，紅黑樹的統計性能高於AVL。
因此，在實際應用中，AVL樹的使用相對較少，而紅黑樹的使用非常廣泛。例如，Java中的TreeMap使用紅黑樹存儲排序鍵值對；Java8中的HashMap使用鏈表+紅黑樹解決哈希沖突問題(當沖突節點較少時，使用鏈表，當沖突節點較多時，使用紅黑樹)。
對於數據在內存中的情況（如上述的TreeMap和HashMap），紅黑樹的表現是非常優異的。但是對於數據在磁盤等輔助存儲設備中的情況（如MySQL等數據庫），紅黑樹並不擅長，因為紅黑樹長得還是太高了。當數據在磁盤中時，磁盤IO會成為最大的性能瓶頸，設計的目標應該是盡量減少IO次數；而樹的高度越高，增刪改查所需要的IO次數也越多，會嚴重影響性能。
B樹：為磁盤而生
為什么要從AVL樹變成B樹？
因為內存的易失性。一般情況下，我們都會選擇將 user 表中的數據和索引存儲在磁盤這種外圍設備中。
但是和內存相比，從磁盤中讀取數據的速度會慢上百倍千倍甚至萬倍，所以，我們應當盡量減少從磁盤中讀取數據的次數。
另外，從磁盤中讀取數據時，都是按照磁盤塊來讀取的，並不是一條一條的讀。
如果我們能把盡量多的數據放進磁盤塊中，那一次磁盤讀取操作就會讀取更多數據，那我們查找數據的時間也會大幅度降低。
如果我們用樹這種數據結構作為索引的數據結構，那我們每查找一次數據就需要從磁盤中讀取一個節點，也就是我們說的一個磁盤塊。
我們都知道平衡二叉樹可是每個節點只存儲一個鍵值和數據的。那說明什么？說明每個磁盤塊僅僅存儲一個鍵值和數據！那如果我們要存儲海量的數據呢？
可以想象到二叉樹的節點將會非常多，高度也會極其高，我們查找數據時也會進行很多次磁盤 IO，我們查找數據的效率將會極低！
因為數據庫是要存儲海量數據的，AVL樹每個節點只儲存一個鍵值和數據，並且數據是存儲在磁盤上，當我們存儲一個鍵值和數據，則速度會很慢，應該減少從磁盤讀取數據的次數。當我們使用AVL樹，樹的高度極高，會進行很多次的磁盤IO，查找數據的效率會降低！
為了解決平衡二叉樹的這個弊端，我們應該尋找一種單個節點可以存儲多個鍵值和數據的平衡樹。也就是我們接下來要說的 B 樹。
B樹——平衡樹
圖中的 p 節點為指向子節點的指針，二叉查找樹和平衡二叉樹其實也有，因為圖的美觀性，被省略了。
圖中的每個節點稱為頁，頁就是我們上面說的磁盤塊，在 MySQL 中數據讀取的基本單位都是頁，所以我們這里叫做頁更符合 MySQL 中索引的底層數據結構。
從上圖可以看出，B 樹相對於平衡二叉樹，每個節點存儲了更多的鍵值（key）和數據（data），並且每個節點擁有更多的子節點，子節點的個數一般稱為階，上述圖中的 B 樹為 3 階 B 樹，高度也會很低。
基於這個特性，B 樹查找數據讀取磁盤的次數將會很少，數據的查找效率也會比平衡二叉樹高很多。
示例：
假如我們要查找 id=28 的用戶信息，那么我們在上圖 B 樹中查找的流程如下：
- 先找到根節點也就是頁 1，判斷 28 在鍵值 17 和 35 之間，那么我們根據頁 1 中的指針 p2 找到頁 3。
- 將 28 和頁 3 中的鍵值相比較，28 在 26 和 30 之間，我們根據頁 3 中的指針 p2 找到頁 8。
- 將 28 和頁 8 中的鍵值相比較，發現有匹配的鍵值 28，鍵值 28 對應的用戶信息為（28，bv）。
應用：B樹在數據庫中有一些應用，如mongodb的索引使用了B樹結構。但是在很多數據庫應用中，使用了是B樹的變種B+樹。
B+樹
根據上圖我們來看下 B+ 樹和 B 樹有什么不同：
① B+ 樹非葉子節點上是不存儲數據的，僅存儲鍵值，而 B 樹節點中不僅存儲鍵值，也會存儲數據。
之所以這么做是因為在數據庫中頁的大小是固定的，InnoDB 中頁的默認大小是 16KB。
如果不存儲數據，那么就會存儲更多的鍵值，相應的樹的階數（節點的子節點樹）就會更大，樹就會更矮更胖，如此一來我們查找數據進行磁盤的 IO 次數又會再次減少，數據查詢的效率也會更快。
另外，B+ 樹的階數是等於鍵值的數量的，如果我們的 B+ 樹一個節點可以存儲 1000 個鍵值，那么 3 層 B+ 樹可以存儲 1000×1000×1000=10 億個數據。
一般根節點是常駐內存的，所以一般我們查找 10 億數據，只需要 2 次磁盤 IO。
② 因為 B+ 樹索引的所有數據均存儲在葉子節點，而且數據是按照順序排列的。
那么 B+ 樹使得范圍查找，排序查找，分組查找以及去重查找變得異常簡單。而 B 樹因為數據分散在各個節點，要實現這一點是很不容易的。
B+ 樹中各個頁之間是通過雙向鏈表連接的，葉子節點中的數據是通過單向鏈表連接的。
其實上面的 B 樹我們也可以對各個節點加上鏈表。這些不是它們之前的區別，是因為在 MySQL 的 InnoDB 存儲引擎中，索引就是這樣存儲的。
也就是說上圖中的 B+ 樹索引就是 InnoDB 中 B+ 樹索引真正的實現方式，准確的說應該是聚集索引（聚集索引和非聚集索引下面會講到）。
通過上圖可以看到，在 InnoDB 中，我們通過數據頁之間通過雙向鏈表連接以及葉子節點中數據之間通過單向鏈表連接的方式可以找到表中所有的數據。
MyISAM 中的 B+ 樹索引實現與 InnoDB 中的略有不同。在 MyISAM 中，B+ 樹索引的葉子節點並不存儲數據，而是存儲數據的文件地址。
為什么B+樹比B樹更適合數據庫索引？
**B樹在提高了IO性能的同時並沒有解決元素遍歷的我效率低下的問題，**B+樹只需要去遍歷葉子節點就可以實現整棵樹的遍歷，而且在數據庫中基於范圍的查詢是非常頻繁的，而B樹不支持這樣的操作或者說效率太低。
B+樹與B樹的不同：
-
B+樹非葉子節點不存在數據只存索引，B樹非葉子節點存儲數據
-
B+樹查詢效率更高。B+樹使用雙向鏈表串連所有葉子節點，區間查詢效率更高（因為所有數據都在B+樹的葉子節點，掃描數據庫 只需掃一遍葉子結點就行了），但是B樹則需要通過中序遍歷才能完成查詢范圍的查找。
-
**B+樹查詢效率更穩定。**B+樹每次都必須查詢到葉子節點才能找到數據，而B樹查詢的數據可能不在葉子節點，也可能在，這樣就會造成查詢的效率的不穩定
-
B+樹的磁盤讀寫代價更小。B+樹的內部節點並沒有指向關鍵字具體信息的指針，因此其內部節點相對B樹更小，通常B+樹矮更胖，高度小查詢產生的I/O更少。
1、 B+樹的磁盤讀寫代價更低：B+樹的內部節點並沒有指向關鍵字具體信息的指針，因此其內部節點相對B樹更小，如果把所有同一內部節點的關鍵字存放在同一盤塊中，那么盤塊所能容納的關鍵字數量也越多，一次性讀入內存的需要查找的關鍵字也就越多，相對IO讀寫次數就降低了。
2、B+樹的查詢效率更加穩定：由於非終結點並不是最終指向文件內容的結點，而只是葉子結點中關鍵字的索引。所以任何關鍵字的查找必須走一條從根結點到葉子結點的路。所有關鍵字查詢的路徑長度相同，導致每一個數據的查詢效率相當。
3、由於B+樹的數據都存儲在葉子結點中，分支結點均為索引，方便掃庫，只需要掃一遍葉子結點即可，但是B樹因為其分支結點同樣存儲着數據，我們要找到具體的數據，需要進行一次中序遍歷按序來掃，所以B+樹更加適合在區間查詢的情況，所以通常B+樹用於數據庫索引。
（2）聚集索引 VS 非聚集索引
那什么是聚集索引呢？在 MySQL 中，B+ 樹索引按照存儲方式的不同分為聚集索引和非聚集索引。
-
**聚集索引（聚簇索引）：**以 InnoDB 作為存儲引擎的表，表中的數據都會有一個主鍵，即使你不創建主鍵，系統也會幫你創建一個隱式的主鍵。
這是因為 InnoDB 是把數據存放在 B+ 樹中的，而 B+ 樹的鍵值就是主鍵，在 B+ 樹的葉子節點中，存儲了表中所有的數據。
這種以主鍵作為 B+ 樹索引的鍵值而構建的 B+ 樹索引，我們稱之為聚集索引。
-
**非聚集索引（非聚簇索引）：**以主鍵以外的列值作為鍵值構建的 B+ 樹索引，我們稱之為非聚集索引。
非聚集索引與聚集索引的區別在於非聚集索引的葉子節點不存儲表中的數據，而是存儲該列對應的主鍵，想要查找數據我們還需要根據主鍵再去聚集索引中進行查找，這個再根據聚集索引查找數據的過程，我們稱為回表。
明白了聚集索引和非聚集索引的定義，我們應該明白這樣一句話：數據即索引，索引即數據。
（3）利用聚集索引和非聚集索引查找數據
如何通過聚集索引以及非聚集索引查找數據表中數據的方式介紹一下 B+ 樹索引查找數據方法。
利用聚集索引查找數據
這就是聚類索引，表中的數據存儲在其中。
舉例：
現在假設我們要查找 id>=18 並且 id<40 的用戶數據。對應的 sql 語句為：
select * from user where id>=18 and id <40
其中 id 為主鍵，具體的查找過程如下：
①一般根節點都是常駐內存的，也就是說頁 1 已經在內存中了，此時不需要到磁盤中讀取數據，直接從內存中讀取即可。
從內存中讀取到頁 1，要查找這個 id>=18 and id <40 或者范圍值，我們首先需要找到 id=18 的鍵值。
從頁 1 中我們可以找到鍵值 18，此時我們需要根據指針 p2，定位到頁 3。
②要從頁 3 中查找數據，我們就需要拿着 p2 指針去磁盤中進行讀取頁 3。
從磁盤中讀取頁 3 后將頁 3 放入內存中，然后進行查找，我們可以找到鍵值 18，然后再拿到頁 3 中的指針 p1，定位到頁 8。
③同樣的頁 8 頁不在內存中，我們需要再去磁盤中將頁 8 讀取到內存中。
將頁 8 讀取到內存中后。因為頁中的數據是鏈表進行連接的，而且鍵值是按照順序存放的，此時可以根據二分查找法定位到鍵值 18。
此時因為已經到數據頁了，此時我們已經找到一條滿足條件的數據了，就是鍵值 18 對應的數據。
因為是范圍查找，而且此時所有的數據又都存在葉子節點，並且是有序排列的，那么我們就可以對頁 8 中的鍵值依次進行遍歷查找並匹配滿足條件的數據。
我們可以一直找到鍵值為 22 的數據，然后頁 8 中就沒有數據了，此時我們需要拿着頁 8 中的 p 指針去讀取頁 9 中的數據。
④因為頁 9 不在內存中，就又會加載頁 9 到內存中，並通過和頁 8 中一樣的方式進行數據的查找，直到將頁 12 加載到內存中，發現 41 大於 40，此時不滿足條件。那么查找到此終止。
最終我們找到滿足條件的所有數據，總共 12 條記錄：
(18,kl), (19,kl), (22,hj), (24,io), (25,vg) , (29,jk), (31,jk) , (33,rt) , (34,ty) , (35,yu) , (37,rt) , (39,rt) 。
利用非聚集索引查找數據
在葉子節點中，不再存儲所有的數據了，存儲的是鍵值和主鍵。對於葉子節點中的 x-y，比如 1-1。左邊的 1 表示的是索引的鍵值，右邊的 1 表示的是主鍵值。
如果我們要找到幸運數字為 33 的用戶信息，對應的 sql 語句為：
select * from user where luckNum=33
查找的流程跟聚集索引一樣，我們最終會找到主鍵值 47，找到主鍵后我們需要再到聚集索引中查找具體對應的數據信息，此時又回到了聚集索引的查找流程。
下面看下具體的查找流程圖：
在 MyISAM 中，聚集索引和非聚集索引的葉子節點都會存儲數據的文件地址。
參考鏈接：劉召考的博客 » MySQL索引-B+樹（看完你就明白了）