為什么Mysql中Innodb的索引結構采取B+樹？

回答這個問題時，給自己留一條后路，不要把B樹噴的一文不值。因為網上有些答案是說，B樹不適合做文件存儲系統的索引結構。如果按照那種答法，自己就給自己挖了一個坑，很難收場。因此，就有了這篇文章的誕生~

文末附面試指南！

正文

這里的Mysql指的是Innodb的存儲引擎下的索引結構，其他存儲引擎我們暫時不討論。

B樹和B+樹

開頭，我們先回憶一下，B樹和B+樹的結構以及特點，如下所示:

B樹

注意一下B樹的兩個明顯特點

樹內的每個節點都存儲數據

葉子節點之間無指針相鄰

B+樹

注意一下B+樹的兩個明顯特點

數據只出現在葉子節點

所有葉子節點增加了一個鏈指針

針對上面的B+樹和B樹的特點，我們做一個總結

(1)B樹的樹內存儲數據，因此查詢單條數據的時候，B樹的查詢效率不固定，最好的情況是O(1)。我們可以認為在做單一數據查詢的時候，使用B樹平均性能更好。但是，由于B樹中各節點之間沒有指針相鄰，因此B樹不適合做一些數據遍歷操作。

(2)B+樹的數據只出現在葉子節點上，因此在查詢單條數據的時候，查詢速度非常穩定。因此，在做單一數據的查詢上，其平均性能并不如B樹。但是，B+樹的葉子節點上有指針進行相連，因此在做數據遍歷的時候，只需要對葉子節點進行遍歷即可，這個特性使得B+樹非常適合做范圍查詢。

因此，我們可以做一個推論:沒準是Mysql中數據遍歷操作比較多，所以用B+樹作為索引結構。而Mongodb是做單一查詢比較多，數據遍歷操作比較少，所以用B樹作為索引結構。

那么為什么Mysql做數據遍歷操作多？而Mongodb做數據遍歷操作少呢？

因為Mysql是關系型數據庫，而Mongodb是非關系型數據。

那為什么關系型數據庫，做數據遍歷操作多？而非關系型數據庫做數據遍歷操作少呢？

我們繼續往下看

關系型VS非關系型

假設，我們此時有兩個邏輯實體:學生(Student)和班級(Class)，這兩個邏輯實體之間是一對多的關系。畢竟一個班級有多個學生，一個學生只能屬于一個班級。

關系型數據庫

我們在關系型數據庫中，考慮的是用幾張表來表示這二者之間的實體關系。常見的無外乎是，一對一關系，用一張表就行。一對多關系，用兩張表。多對多關系，用三張表。

那這里，我們需要用兩張表表示二者之間邏輯關系，如下所示

那我們，此時要查cname為1班的班級，有多少學生怎么辦？

假設cname這列，我們建了索引！

執行SQL，如下所示！

SELECT *

FROM t_student t1, (

SELECT cid

FROM t_class

WHERE cname = '1班'

) t2

WHERE t1.cid = t2.cid

而這，就涉及到了數據遍歷操作！

因為但凡做這種關聯查詢，你躲不開join操作的！既然涉及到了join操作，無外乎從一個表中取一個數據，去另一個表中逐行匹配，如果索引結構是B+樹，葉子節點上是有指針的，能夠極大的提高這種一行一行的匹配速度！

有的人或許會抬杠說，如果我先執行

SELECT cid

FROM t_class

WHERE cname = '1班'

獲得cid后，再去循環執行

SELECT *

FROM t_student

WHERE cid = ...

就可以避開join操作呀？

對此，我想說。你確實避開了join操作，但是你數據遍歷操作還是沒避開。你還是需要在student的這張表的葉子節點上，一遍又一遍的遍歷！

那在非關系型數據庫中，我們如何查詢cname為1班的班級，有多少學生？

非關系型數據庫

有人說，你可以這么設計？也就是弄兩個集合如下所示

然后勒，執行兩次查詢去獲得結果！

確實，這么設計是可以的，我沒說不行。只是不符合非關系型數據庫的設計初衷。在MongoDB中，根本不推薦這么設計。雖然，Mongodb中有一個lookup操作，可以做join查詢。但是理想情況下，這個lookup操作，可以做join查詢。但是理想情況下，這個lookup操作應該不會經常使用，如果你需要經常使用它，那么你就使用了錯誤的數據存儲了(數據庫)：如果你有相關聯的數據，應該使用關系型數據庫(SQL)。

因此，正規的設計應該如下

假設name這列，我們建了索引！

我只尋執行一次語句

db.class.find( { name: '1班' } )

這樣就能查詢出自己想要的結果。

而這，就是一種單一數據查詢!畢竟你不需要去逐行匹配，不涉及遍歷操作,幸運的情況下，有可能一次IO就能夠得到你想要的結果。

因此，由于關系型數據庫和非關系型數據的設計方式上的不同。導致在關系型數據中，遍歷操作比較常見，因此采用B+樹作為索引，比較合適。而在非關系型數據庫中，單一查詢比較常見，因此采用B樹作為索引，比較合適。

面試套路

目前套路有如下幾種

套路一

你簡歷寫了mysql，沒寫mongodb!

面試官:"說說mysql索引結構？"

我:"巴拉巴拉"

面試官:"知道為什么用B+樹，不用B樹么？"

這個時候正常的面試者就蒙了，會把B樹的缺點噴一通！于是乎下一問就是

面試官:"其實一些非關系型數據庫，如mongodb用的就是B樹，你知道原因么？"

然后你就回去等通知了！

套路二

你簡歷寫了mysql，也寫了mongodb!

這種情況更完美！

面試官:"說說mysql索引結構？"

我:"巴拉巴拉"

面試官:"你簡歷寫了Mongodb，有了解過他的索引結構么？"

我:"巴拉巴拉"

面試官:"為什么Mongodb索引用B樹，而Mysql用B+樹？"

然后你就回去等通知了！

套路三

你簡歷既沒寫mysql，沒寫mongodb!

面試官；"如果你來設計數據庫，你會對他的索引用什么數據結構？"

我:"首先不考慮紅黑樹這類，巴拉巴拉...應該會用B樹或者B+樹。"

面試官；“如果我要設計一個像Mongodb那樣的非關系型數據庫，我要用什么數據結構當索引比較合適?”

然后你就可以回去等通知了！

總結

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

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