索引是一種數(shù)據(jù)結(jié)構(gòu)雕欺，用于幫助我們在大量數(shù)據(jù)中快速定位到我們想要查找的數(shù)據(jù)。

索引最形象的比喻就是圖書的目錄了掸驱。注意這里的大量陨收，數(shù)據(jù)量大了索引才顯得有意義饭豹，如果我想要在 [1,2,3,4] 中找到 4 這個數(shù)據(jù)，直接對全數(shù)據(jù)檢索也很快务漩，沒有必要費力氣建索引再去查找墨状。

索引在 MySQL 數(shù)據(jù)庫中分三類：

B+ 樹索引

Hash 索引

全文索引

我們今天要介紹的是工作開發(fā)中最常接觸到的 InnoDB 存儲引擎中的 B+ 樹索引。要介紹 B+ 樹索引菲饼，就不得不提二叉查找樹肾砂，平衡二叉樹和 B 樹這三種數(shù)據(jù)結(jié)構(gòu)。B+ 樹就是從他們仨演化來的宏悦。

二叉查找樹

首先镐确，讓我們先看一張圖：

從圖中可以看到，我們?yōu)?user 表（用戶信息表）建立了一個二叉查找樹的索引饼煞。

圖中的圓為二叉查找樹的節(jié)點源葫，節(jié)點中存儲了鍵（key）和數(shù)據(jù)（data）。鍵對應(yīng) user 表中的 id砖瞧，數(shù)據(jù)對應(yīng) user 表中的行數(shù)據(jù)息堂。

二叉查找樹的特點就是任何節(jié)點的左子節(jié)點的鍵值都小于當(dāng)前節(jié)點的鍵值，右子節(jié)點的鍵值都大于當(dāng)前節(jié)點的鍵值。頂端的節(jié)點我們稱為根節(jié)點荣堰，沒有子節(jié)點的節(jié)點我們稱之為葉節(jié)點床未。

如果我們需要查找 id=12 的用戶信息，利用我們創(chuàng)建的二叉查找樹索引振坚，查找流程如下：

將根節(jié)點作為當(dāng)前節(jié)點薇搁，把 12 與當(dāng)前節(jié)點的鍵值 10 比較，12 大于 10渡八，接下來我們把當(dāng)前節(jié)點>的右子節(jié)點作為當(dāng)前節(jié)點啃洋。

繼續(xù)把 12 和當(dāng)前節(jié)點的鍵值 13 比較，發(fā)現(xiàn) 12 小于 13屎鳍，把當(dāng)前節(jié)點的左子節(jié)點作為當(dāng)前節(jié)點宏娄。

把 12 和當(dāng)前節(jié)點的鍵值 12 對比，12 等于 12逮壁，滿足條件孵坚，我們從當(dāng)前節(jié)點中取出 data，即 id=12貌踏，name=xm十饥。

利用二叉查找樹我們只需要 3 次即可找到匹配的數(shù)據(jù)窟勃。如果在表中一條條的查找的話祖乳，我們需要 6 次才能找到。

平衡二叉樹

上面我們講解了利用二叉查找樹可以快速的找到數(shù)據(jù)秉氧。但是眷昆，如果上面的二叉查找樹是這樣的構(gòu)造：

這個時候可以看到我們的二叉查找樹變成了一個鏈表。如果我們需要查找 id=17 的用戶信息汁咏，我們需要查找 7 次亚斋，也就相當(dāng)于全表掃描了。?

導(dǎo)致這個現(xiàn)象的原因其實是二叉查找樹變得不平衡了攘滩，也就是高度太高了帅刊，從而導(dǎo)致查找效率的不穩(wěn)定。

為了解決這個問題漂问，我們需要保證二叉查找樹一直保持平衡赖瞒，就需要用到平衡二叉樹了。?

平衡二叉樹又稱 AVL 樹蚤假，在滿足二叉查找樹特性的基礎(chǔ)上栏饮，要求每個節(jié)點的左右子樹的高度差不能超過 1。?

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

由平衡二叉樹的構(gòu)造我們可以發(fā)現(xiàn)第一張圖中的二叉樹其實就是一棵平衡二叉樹磷仰。

平衡二叉樹保證了樹的構(gòu)造是平衡的袍嬉，當(dāng)我們插入或刪除數(shù)據(jù)導(dǎo)致不滿足平衡二叉樹不平衡時，平衡二叉樹會進行調(diào)整樹上的節(jié)點來保持平衡。具體的調(diào)整方式這里就不介紹了伺通。

平衡二叉樹相比于二叉查找樹來說箍土，查找效率更穩(wěn)定，總體的查找速度也更快泵殴。

B 樹

因為內(nèi)存的易失性涮帘。一般情況下，我們都會選擇將 user 表中的數(shù)據(jù)和索引存儲在磁盤這種外圍設(shè)備中笑诅。

但是和內(nèi)存相比调缨，從磁盤中讀取數(shù)據(jù)的速度會慢上百倍千倍甚至萬倍，所以吆你，我們應(yīng)當(dāng)盡量減少從磁盤中讀取數(shù)據(jù)的次數(shù)弦叶。

另外，從磁盤中讀取數(shù)據(jù)時妇多，都是按照磁盤塊來讀取的伤哺，并不是一條一條的讀。

如果我們能把盡量多的數(shù)據(jù)放進磁盤塊中者祖，那一次磁盤讀取操作就會讀取更多數(shù)據(jù)立莉，那我們查找數(shù)據(jù)的時間也會大幅度降低。

如果我們用樹這種數(shù)據(jù)結(jié)構(gòu)作為索引的數(shù)據(jù)結(jié)構(gòu)七问，那我們每查找一次數(shù)據(jù)就需要從磁盤中讀取一個節(jié)點蜓耻，也就是我們說的一個磁盤塊。

我們都知道平衡二叉樹可是每個節(jié)點只存儲一個鍵值和數(shù)據(jù)的械巡。那說明什么刹淌？說明每個磁盤塊僅僅存儲一個鍵值和數(shù)據(jù)！那如果我們要存儲海量的數(shù)據(jù)呢讥耗？

可以想象到二叉樹的節(jié)點將會非常多有勾，高度也會極其高，我們查找數(shù)據(jù)時也會進行很多次磁盤 IO古程，我們查找數(shù)據(jù)的效率將會極低蔼卡！

為了解決平衡二叉樹的這個弊端，我們應(yīng)該尋找一種單個節(jié)點可以存儲多個鍵值和數(shù)據(jù)的平衡樹挣磨。也就是我們接下來要說的 B 樹雇逞。

B 樹（Balance Tree）即為平衡樹的意思，下圖即是一棵?B 樹：

圖中的 p 節(jié)點為指向子節(jié)點的指針趋急，二叉查找樹和平衡二叉樹其實也有喝峦，因為圖的美觀性，被省略了呜达。

圖中的每個節(jié)點稱為頁谣蠢，頁就是我們上面說的磁盤塊，在 MySQL 中數(shù)據(jù)讀取的基本單位都是頁，所以我們這里叫做頁更符合 MySQL 中索引的底層數(shù)據(jù)結(jié)構(gòu)眉踱。

從上圖可以看出挤忙，B 樹相對于平衡二叉樹，每個節(jié)點存儲了更多的鍵值（key）和數(shù)據(jù)（data）谈喳，并且每個節(jié)點擁有更多的子節(jié)點册烈，子節(jié)點的個數(shù)一般稱為階，上述圖中的 B 樹為 3 階 B 樹婿禽，高度也會很低赏僧。

基于這個特性，B 樹查找數(shù)據(jù)讀取磁盤的次數(shù)將會很少扭倾，數(shù)據(jù)的查找效率也會比平衡二叉樹高很多淀零。

假如我們要查找 id=28 的用戶信息，那么我們在上圖 B 樹中查找的流程如下：

先找到根節(jié)點也就是頁 1膛壹，判斷 28 在鍵值 17 和 35 之間驾中，那么我們根據(jù)頁 1 中的指針 p2 找到頁 3。

將 28 和頁 3 中的鍵值相比較模聋，28 在 26 和 30 之間肩民，我們根據(jù)頁 3 中的指針 p2 找到頁 8。

將?28 和頁 8 中的鍵值相比較链方，發(fā)現(xiàn)有匹配的鍵值 28持痰，鍵值 28 對應(yīng)的用戶信息為（28，bv）侄柔。

B+ 樹

B+?樹是對 B 樹的進一步優(yōu)化共啃。讓我們先來看下 B+ 樹的結(jié)構(gòu)圖：

根據(jù)上圖我們來看下 B+?樹和 B 樹有什么不同：

①B+?樹非葉子節(jié)點上是不存儲數(shù)據(jù)的占调，僅存儲鍵值暂题，而 B 樹節(jié)點中不僅存儲鍵值，也會存儲數(shù)據(jù)究珊。

之所以這么做是因為在數(shù)據(jù)庫中頁的大小是固定的薪者，InnoDB 中頁的默認(rèn)大小是 16KB。

如果不存儲數(shù)據(jù)剿涮，那么就會存儲更多的鍵值言津，相應(yīng)的樹的階數(shù)（節(jié)點的子節(jié)點樹）就會更大，樹就會更矮更胖取试，如此一來我們查找數(shù)據(jù)進行磁盤的 IO 次數(shù)又會再次減少悬槽，數(shù)據(jù)查詢的效率也會更快。

另外瞬浓，B+ 樹的階數(shù)是等于鍵值的數(shù)量的初婆，如果我們的 B+ 樹一個節(jié)點可以存儲 1000?個鍵值，那么 3 層 B+ 樹可以存儲 1000×1000×1000=10 億個數(shù)據(jù)。

一般根節(jié)點是常駐內(nèi)存的磅叛，所以一般我們查找 10 億數(shù)據(jù)屑咳，只需要 2 次磁盤 IO。

②因為 B+ 樹索引的所有數(shù)據(jù)均存儲在葉子節(jié)點弊琴，而且數(shù)據(jù)是按照順序排列的兆龙。

那么 B+ 樹使得范圍查找，排序查找敲董，分組查找以及去重查找變得異常簡單紫皇。而 B 樹因為數(shù)據(jù)分散在各個節(jié)點，要實現(xiàn)這一點是很不容易的腋寨。

有心的讀者可能還發(fā)現(xiàn)上圖 B+ 樹中各個頁之間是通過雙向鏈表連接的坝橡，葉子節(jié)點中的數(shù)據(jù)是通過單向鏈表連接的。

其實上面的 B 樹我們也可以對各個節(jié)點加上鏈表精置。這些不是它們之前的區(qū)別计寇，是因為在 MySQL 的 InnoDB 存儲引擎中，索引就是這樣存儲的脂倦。

也就是說上圖中的 B+ 樹索引就是 InnoDB 中 B+ 樹索引真正的實現(xiàn)方式番宁，準(zhǔn)確的說應(yīng)該是聚集索引（聚集索引和非聚集索引下面會講到）。

通過上圖可以看到赖阻，在 InnoDB 中蝶押，我們通過數(shù)據(jù)頁之間通過雙向鏈表連接以及葉子節(jié)點中數(shù)據(jù)之間通過單向鏈表連接的方式可以找到表中所有的數(shù)據(jù)。

MyISAM 中的 B+ 樹索引實現(xiàn)與 InnoDB 中的略有不同火欧。在 MyISAM 中棋电，B+ 樹索引的葉子節(jié)點并不存儲數(shù)據(jù)，而是存儲數(shù)據(jù)的文件地址苇侵。

聚集索引 VS?非聚集索引

在上節(jié)介紹 B+ 樹索引的時候赶盔，我們提到了圖中的索引其實是聚集索引的實現(xiàn)方式。

那什么是聚集索引呢榆浓？在 MySQL 中于未，B+ 樹索引按照存儲方式的不同分為聚集索引和非聚集索引。

這里我們著重介紹 InnoDB 中的聚集索引和非聚集索引：

①聚集索引（聚簇索引）：以 InnoDB 作為存儲引擎的表陡鹃，表中的數(shù)據(jù)都會有一個主鍵烘浦，即使你不創(chuàng)建主鍵，系統(tǒng)也會幫你創(chuàng)建一個隱式的主鍵萍鲸。

這是因為 InnoDB 是把數(shù)據(jù)存放在 B+ 樹中的闷叉，而 B+?樹的鍵值就是主鍵，在 B+?樹的葉子節(jié)點中脊阴，存儲了表中所有的數(shù)據(jù)握侧。

這種以主鍵作為 B+ 樹索引的鍵值而構(gòu)建的 B+?樹索引捌肴，我們稱之為聚集索引。

②非聚集索引（非聚簇索引）：以主鍵以外的列值作為鍵值構(gòu)建的 B+ 樹索引藕咏，我們稱之為非聚集索引状知。

非聚集索引與聚集索引的區(qū)別在于非聚集索引的葉子節(jié)點不存儲表中的數(shù)據(jù)，而是存儲該列對應(yīng)的主鍵孽查，想要查找數(shù)據(jù)我們還需要根據(jù)主鍵再去聚集索引中進行查找饥悴，這個再根據(jù)聚集索引查找數(shù)據(jù)的過程，我們稱為回表盲再。

明白了聚集索引和非聚集索引的定義西设，我們應(yīng)該明白這樣一句話：數(shù)據(jù)即索引，索引即數(shù)據(jù)答朋。

利用聚集索引和非聚集索引查找數(shù)據(jù)

前面我們講解 B+ 樹索引的時候并沒有去說怎么在 B+ 樹中進行數(shù)據(jù)的查找贷揽，主要就是因為還沒有引出聚集索引和非聚集索引的概念。

下面我們通過講解如何通過聚集索引以及非聚集索引查找數(shù)據(jù)表中數(shù)據(jù)的方式介紹一下 B+ 樹索引查找數(shù)據(jù)方法梦碗。

利用聚集索引查找數(shù)據(jù)

還是這張 B+ 樹索引圖禽绪，現(xiàn)在我們應(yīng)該知道這就是聚集索引，表中的數(shù)據(jù)存儲在其中洪规。

現(xiàn)在假設(shè)我們要查找 id>=18 并且 id<40?的用戶數(shù)據(jù)印屁。對應(yīng)的 sql 語句為：

MySQL

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

其中 id 為主鍵，具體的查找過程如下：

①一般根節(jié)點都是常駐內(nèi)存的斩例，也就是說頁 1 已經(jīng)在內(nèi)存中了雄人，此時不需要到磁盤中讀取數(shù)據(jù)，直接從內(nèi)存中讀取即可念赶。

從內(nèi)存中讀取到頁 1础钠，要查找這個 id>=18 and id <40?或者范圍值，我們首先需要找到 id=18 的鍵值叉谜。

從頁 1 中我們可以找到鍵值 18旗吁，此時我們需要根據(jù)指針 p2，定位到頁 3正罢。

②要從頁 3 中查找數(shù)據(jù)阵漏，我們就需要拿著 p2 指針去磁盤中進行讀取頁 3驻民。

從磁盤中讀取頁 3 后將頁 3 放入內(nèi)存中翻具，然后進行查找，我們可以找到鍵值 18回还，然后再拿到頁 3 中的指針 p1裆泳，定位到頁 8。

③同樣的頁 8 頁不在內(nèi)存中柠硕，我們需要再去磁盤中將頁 8 讀取到內(nèi)存中工禾。

將頁 8 讀取到內(nèi)存中后运提。因為頁中的數(shù)據(jù)是鏈表進行連接的，而且鍵值是按照順序存放的闻葵，此時可以根據(jù)二分查找法定位到鍵值 18民泵。

此時因為已經(jīng)到數(shù)據(jù)頁了，此時我們已經(jīng)找到一條滿足條件的數(shù)據(jù)了槽畔，就是鍵值 18 對應(yīng)的數(shù)據(jù)栈妆。

因為是范圍查找，而且此時所有的數(shù)據(jù)又都存在葉子節(jié)點厢钧，并且是有序排列的鳞尔，那么我們就可以對頁 8 中的鍵值依次進行遍歷查找并匹配滿足條件的數(shù)據(jù)。

我們可以一直找到鍵值為 22 的數(shù)據(jù)早直，然后頁 8 中就沒有數(shù)據(jù)了寥假，此時我們需要拿著頁 8 中的 p 指針去讀取頁 9 中的數(shù)據(jù)。

④因為頁 9 不在內(nèi)存中霞扬，就又會加載頁 9 到內(nèi)存中糕韧，并通過和頁 8 中一樣的方式進行數(shù)據(jù)的查找，直到將頁 12 加載到內(nèi)存中喻圃，發(fā)現(xiàn) 41 大于 40兔沃，此時不滿足條件。那么查找到此終止级及。

最終我們找到滿足條件的所有數(shù)據(jù)乒疏，總共 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) 。

下面看下具體的查找流程圖

利用非聚集索引查找數(shù)據(jù)

讀者看到這張圖的時候可能會蒙饮焦，這是啥東西芭挛狻？怎么都是數(shù)字县踢。如果有這種感覺转绷，請仔細(xì)看下圖中紅字的解釋。

什么硼啤？還看不懂议经？那我再來解釋下吧。首先谴返，這個非聚集索引表示的是用戶幸運數(shù)字的索引（為什么是幸運數(shù)字煞肾？一時興起想起來的:-)），此時表結(jié)構(gòu)是這樣的嗓袱。

在葉子節(jié)點中籍救，不再存儲所有的數(shù)據(jù)了，存儲的是鍵值和主鍵渠抹。對于葉子節(jié)點中的 x-y蝙昙，比如 1-1闪萄。左邊的 1 表示的是索引的鍵值，右邊的 1 表示的是主鍵值奇颠。

如果我們要找到幸運數(shù)字為 33 的用戶信息败去，對應(yīng)的 sql 語句為：

MySQL

1select * from user where luckNum=33

查找的流程跟聚集索引一樣，這里就不詳細(xì)介紹了烈拒。我們最終會找到主鍵值 47为迈，找到主鍵后我們需要再到聚集索引中查找具體對應(yīng)的數(shù)據(jù)信息，此時又回到了聚集索引的查找流程缺菌。

下面看下具體的查找流程圖：

在 MyISAM 中葫辐，聚集索引和非聚集索引的葉子節(jié)點都會存儲數(shù)據(jù)的文件地址。

總結(jié)

本篇文章從二叉查找樹伴郁，詳細(xì)說明了為什么 MySQL 用 B+ 樹作為數(shù)據(jù)的索引耿战，以及在 InnoDB 中數(shù)據(jù)庫如何通過 B+?樹索引來存儲數(shù)據(jù)以及查找數(shù)據(jù)。

我們一定要記住這句話：數(shù)據(jù)即索引焊傅，索引即數(shù)據(jù)剂陡。

轉(zhuǎn)自劉召考的博客 ? MySQL索引-B+樹（看完你就明白了）