B樹？這篇文章完全看懂了！

前言

索引，相信大多數人已經至關熟悉了，不少人都知道 MySQL 的索引主要以 B+ 樹爲主，可是要問到爲何用 B+ 樹，恐怕不多有人能把來龍去脈講述完整。本文就來從頭至尾介紹下數據庫的索引。

索引是一種數據結構，用於幫助咱們在大量數據中快速定位到咱們想要查找的數據。

索引最形象的比喻就是圖書的目錄了。注意這裏的大量，數據量大了索引才顯得有意義，若是我想要在 [1,2,3,4] 中找到 4 這個數據，直接對全數據檢索也很快，沒有必要費力氣建索引再去查找。

索引在 MySQL 數據庫中分三類：

• B+ 樹索引

• Hash 索引

• 全文索引

咱們今天要介紹的是工做開發中最常接觸到的 InnoDB 存儲引擎中的 B+ 樹索引。

要介紹 B+ 樹索引，就不得不提二叉查找樹，平衡二叉樹和 B 樹這三種數據結構。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。

利用二叉查找樹咱們只須要 3 次便可找到匹配的數據。若是在表中一條條的查找的話，咱們須要 6 次才能找到。

平衡二叉樹

上面咱們講解了利用二叉查找樹能夠快速的找到數據。可是，若是上面的二叉查找樹是這樣的構造：

這個時候能夠看到咱們的二叉查找樹變成了一個鏈表。若是咱們須要查找 id=17 的用戶信息，咱們須要查找 7 次，也就至關於全表掃描了。

致使這個現象的緣由實際上是二叉查找樹變得不平衡了，也就是高度過高了，從而致使查找效率的不穩定。

爲了解決這個問題，咱們須要保證二叉查找樹一直保持平衡，就須要用到平衡二叉樹了。

平衡二叉樹又稱 AVL 樹，在知足二叉查找樹特性的基礎上，要求每一個節點的左右子樹的高度差不能超過 1。

下面是平衡二叉樹和非平衡二叉樹的對比：

由平衡二叉樹的構造咱們能夠發現第一張圖中的二叉樹其實就是一棵平衡二叉樹。

平衡二叉樹保證了樹的構造是平衡的，當咱們插入或刪除數據致使不知足平衡二叉樹不平衡時，平衡二叉樹會進行調整樹上的節點來保持平衡。具體的調整方式這裏就不介紹了。

平衡二叉樹相比於二叉查找樹來講，查找效率更穩定，整體的查找速度也更快。

B 樹

由於內存的易失性。通常狀況下，咱們都會選擇將 user 表中的數據和索引存儲在磁盤這種外圍設備中。

可是和內存相比，從磁盤中讀取數據的速度會慢上百倍千倍甚至萬倍，因此，咱們應當儘可能減小從磁盤中讀取數據的次數。

另外，從磁盤中讀取數據時，都是按照磁盤塊來讀取的，並非一條一條的讀。

若是咱們能把儘可能多的數據放進磁盤塊中，那一次磁盤讀取操做就會讀取更多數據，那咱們查找數據的時間也會大幅度下降。

若是咱們用樹這種數據結構做爲索引的數據結構，那咱們每查找一次數據就須要從磁盤中讀取一個節點，也就是咱們說的一個磁盤塊。

咱們都知道平衡二叉樹但是每一個節點只存儲一個鍵值和數據的。那說明什麼？說明每一個磁盤塊僅僅存儲一個鍵值和數據！那若是咱們要存儲海量的數據呢？

能夠想象到二叉樹的節點將會很是多，高度也會極其高，咱們查找數據時也會進行不少次磁盤 IO，咱們查找數據的效率將會極低！

爲了解決平衡二叉樹的這個弊端，咱們應該尋找一種單個節點能夠存儲多個鍵值和數據的平衡樹。也就是咱們接下來要說的 B 樹。

B 樹（Balance Tree）即爲平衡樹的意思，下圖便是一棵 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+ 樹

B+ 樹是對 B 樹的進一步優化。讓咱們先來看下 B+ 樹的結構圖：

根據上圖咱們來看下 B+ 樹和 B 樹有什麼不一樣：

（1）B+ 樹非葉子節點上是不存儲數據的，僅存儲鍵值，而 B 樹節點中不只存儲鍵值，也會存儲數據。

之因此這麼作是由於在數據庫中頁的大小是固定的，InnoDB 中頁的默認大小是 16KB。

若是不存儲數據，那麼就會存儲更多的鍵值，相應的樹的階數（節點的子節點樹）就會更大，樹就會更矮更胖，如此一來咱們查找數據進行磁盤的 IO 次數又會再次減小，數據查詢的效率也會更快。

另外，B+ 樹的階數是等於鍵值的數量的，若是咱們的 B+ 樹一個節點能夠存儲 1000 個鍵值，那麼 3 層 B+ 樹能夠存儲 1000×1000×1000=10 億個數據。

通常根節點是常駐內存的，因此通常咱們查找 10 億數據，只須要 2 次磁盤 IO。

（2）由於 B+ 樹索引的全部數據均存儲在葉子節點，並且數據是按照順序排列的。

那麼 B+ 樹使得範圍查找，排序查找，分組查找以及去重查找變得異常簡單。而 B 樹由於數據分散在各個節點，要實現這一點是很不容易的。  

有心的讀者可能還發現上圖 B+ 樹中各個頁之間是經過雙向鏈表鏈接的，葉子節點中的數據是經過單向鏈表鏈接的。

其實上面的 B 樹咱們也能夠對各個節點加上鍊表。這些不是它們以前的區別，是由於在 MySQL 的 InnoDB 存儲引擎中，索引就是這樣存儲的。

也就是說上圖中的 B+ 樹索引就是 InnoDB 中 B+ 樹索引真正的實現方式，準確的說應該是彙集索引（彙集索引和非彙集索引下面會講到）。

經過上圖能夠看到，在 InnoDB 中，咱們經過數據頁之間經過雙向鏈表鏈接以及葉子節點中數據之間經過單向鏈表鏈接的方式能夠找到表中全部的數據。

MyISAM 中的 B+ 樹索引實現與 InnoDB 中的略有不一樣。在 MyISAM 中，B+ 樹索引的葉子節點並不存儲數據，而是存儲數據的文件地址。

彙集索引 VS 非彙集索引

在上節介紹 B+ 樹索引的時候，咱們提到了圖中的索引實際上是彙集索引的實現方式。

那什麼是彙集索引呢？在 MySQL 中，B+ 樹索引按照存儲方式的不一樣分爲彙集索引和非彙集索引。

這裏咱們着重介紹 InnoDB 中的彙集索引和非彙集索引：

（1）彙集索引（聚簇索引）：以 InnoDB 做爲存儲引擎的表，表中的數據都會有一個主鍵，即便你不建立主鍵，系統也會幫你建立一個隱式的主鍵。

這是由於 InnoDB 是把數據存放在 B+ 樹中的，而 B+ 樹的鍵值就是主鍵，在 B+ 樹的葉子節點中，存儲了表中全部的數據。歡迎你們關注個人公種浩【程序員追風】，文章都會在裏面更新，整理的資料也會放在裏面。

這種以主鍵做爲 B+ 樹索引的鍵值而構建的 B+ 樹索引，咱們稱之爲彙集索引。

（2）非彙集索引（非聚簇索引）：以主鍵之外的列值做爲鍵值構建的 B+ 樹索引，咱們稱之爲非彙集索引。

非彙集索引與彙集索引的區別在於非彙集索引的葉子節點不存儲表中的數據，而是存儲該列對應的主鍵，想要查找數據咱們還須要根據主鍵再去彙集索引中進行查找，這個再根據彙集索引查找數據的過程，咱們稱爲回表。

明白了彙集索引和非彙集索引的定義，咱們應該明白這樣一句話：數據即索引，索引即數據。

利用匯集索引和非彙集索引查找數據

前面咱們講解 B+ 樹索引的時候並無去說怎麼在 B+ 樹中進行數據的查找，主要就是由於尚未引出彙集索引和非彙集索引的概念。

下面咱們經過講解如何經過彙集索引以及非彙集索引查找數據表中數據的方式介紹一下 B+ 樹索引查找數據方法。

利用匯集索引查找數據

仍是這張 B+ 樹索引圖，如今咱們應該知道這就是彙集索引，表中的數據存儲在其中。

如今假設咱們要查找 id>=18 而且 id<40 的用戶數據。對應的 sql 語句爲：

select * from user where id>=18 and id <40

其中 id 爲主鍵，具體的查找過程以下：

（1）通常根節點都是常駐內存的，也就是說頁 1 已經在內存中了，此時不須要到磁盤中讀取數據，直接從內存中讀取便可。

從內存中讀取到頁 1，要查找這個 id>=18 and id <40 或者範圍值，咱們首先須要找到 id=18 的鍵值。

從頁 1 中咱們能夠找到鍵值 18，此時咱們須要根據指針 p2，定位到頁 3。

（2）要從頁 3 中查找數據，咱們就須要拿着 p2 指針去磁盤中進行讀取頁 3。

從磁盤中讀取頁 3 後將頁 3 放入內存中，而後進行查找，咱們能夠找到鍵值 18，而後再拿到頁 3 中的指針 p1，定位到頁 8。

（3）一樣的頁 8 頁不在內存中，咱們須要再去磁盤中將頁 8 讀取到內存中。

將頁 8 讀取到內存中後。由於頁中的數據是鏈表進行鏈接的，並且鍵值是按照順序存放的，此時能夠根據二分查找法定位到鍵值 18。

此時由於已經到數據頁了，此時咱們已經找到一條知足條件的數據了，就是鍵值 18 對應的數據。

由於是範圍查找，並且此時全部的數據又都存在葉子節點，而且是有序排列的，那麼咱們就能夠對頁 8 中的鍵值依次進行遍歷查找並匹配知足條件的數據。

咱們能夠一直找到鍵值爲 22 的數據，而後頁 8 中就沒有數據了，此時咱們須要拿着頁 8 中的 p 指針去讀取頁 9 中的數據。

（4）由於頁 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+ 樹做爲數據的索引，以及在 InnoDB 中數據庫如何經過 B+ 樹索引來存儲數據以及查找數據。

咱們必定要記住這句話：數據即索引，索引即數據。

最後

歡迎你們一塊兒交流，喜歡文章記得點個贊喲，感謝支持！