這里的Mysql指的是Innodb的存儲引擎下的索引結構螟深，其他存儲引擎我們暫時不討論。
B樹和B+樹
開頭蜗顽，我們先回憶一下布卡，B樹和B+樹的結構以及特點，如下所示:B樹
樹內(nèi)的每個節(jié)點都存儲數(shù)據(jù)
葉子節(jié)點之間無指針相鄰
B+樹
注意一下B+樹的兩個明顯特點
數(shù)據(jù)只出現(xiàn)在葉子節(jié)點
所有葉子節(jié)點增加了一個鏈指針
針對上面的B+樹和B樹的特點雇盖，我們做一個總結(1)B樹的樹內(nèi)存儲數(shù)據(jù)忿等，因此查詢單條數(shù)據(jù)的時候，B樹的查詢效率不固定崔挖，最好的情況是O(1)贸街。我們可以認為在做單一數(shù)據(jù)查詢的時候，使用B樹平均性能更好狸相。但是薛匪，由于B樹中各節(jié)點之間沒有指針相鄰，因此B樹不適合做一些數(shù)據(jù)遍歷操作脓鹃。
(2)B+樹的數(shù)據(jù)只出現(xiàn)在葉子節(jié)點上逸尖，因此在查詢單條數(shù)據(jù)的時候，查詢速度非常穩(wěn)定瘸右。因此娇跟，在做單一數(shù)據(jù)的查詢上，其平均性能并不如B樹太颤。但是苞俘，B+樹的葉子節(jié)點上有指針進行相連，因此在做數(shù)據(jù)遍歷的時候龄章，只需要對葉子節(jié)點進行遍歷即可吃谣，這個特性使得B+樹非常適合做范圍查詢。
因此做裙，我們可以做一個推論:沒準是Mysql中數(shù)據(jù)遍歷操作比較多岗憋，所以用B+樹作為索引結構。而Mongodb是做單一查詢比較多锚贱，數(shù)據(jù)遍歷操作比較少澜驮，所以用B樹作為索引結構。
那么為什么Mysql做數(shù)據(jù)遍歷操作多惋鸥？而Mongodb做數(shù)據(jù)遍歷操作少呢杂穷？因為Mysql是關系型數(shù)據(jù)庫悍缠，而Mongodb是非關系型數(shù)據(jù)。
那為什么關系型數(shù)據(jù)庫耐量，做數(shù)據(jù)遍歷操作多飞蚓？
而非關系型數(shù)據(jù)庫，做數(shù)據(jù)遍歷操作少呢廊蜒？我們繼續(xù)往下看
關系型VS非關系型
假設趴拧，我們此時有兩個邏輯實體:學生(Student)和班級(Class)，這兩個邏輯實體之間是一對多的關系山叮。畢竟一個班級有多個學生著榴，一個學生只能屬于一個班級。關系型數(shù)據(jù)庫我們在關系型數(shù)據(jù)庫中屁倔，考慮的是用幾張表來表示這二者之間的實體關系脑又。常見的無外乎是，一對一關系锐借，用一張表就行问麸。一對多關系，用兩張表钞翔。多對多關系严卖，用三張表。那這里布轿，我們需要用兩張表表示二者之間邏輯關系哮笆，如下所示
cname
1班
cname
SELECT *
FROM t_student t1, (
? ? ?? SELECT cid
? ? ?? FROM t_class
? ? ?? WHERE cname = '1班'
?? ) t2
WHERE t1.cid = t2.cid
而這，就涉及到了數(shù)據(jù)遍歷操作汰扭！
因為但凡做這種關聯(lián)查詢疟呐，你躲不開join操作的！既然涉及到了join操作东且，無外乎從一個表中取一個數(shù)據(jù)，去另一個表中逐行匹配本讥，如果索引結構是B+樹珊泳，葉子節(jié)點上是有指針的，能夠極大的提高這種一行一行的匹配速度拷沸！
有的人或許會抬杠說色查，如果我先執(zhí)行
SELECT cid
FROM t_class
WHERE cname = '1班'
獲得cid后，再去循環(huán)執(zhí)行
SELECT *
FROM t_student
WHERE cid = ...
就可以避開join操作呀撞芍？
對此秧了，我想說。你確實避開了join操作序无，但是你數(shù)據(jù)遍歷操作還是沒避開验毡。你還是需要在student的這張表的葉子節(jié)點上衡创，一遍又一遍的遍歷！
那在非關系型數(shù)據(jù)庫中晶通，我們?nèi)绾尾樵僣name為1班的班級璃氢，有多少學生？非關系型數(shù)據(jù)庫有人說狮辽，你可以這么設計一也？也就是弄兩個集合如下所示
確實，這么設計是可以的喉脖，我沒說不行椰苟。只是不符合非關系型數(shù)據(jù)庫的設計初衷。在MongoDB中树叽，根本不推薦這么設計舆蝴。雖然，Mongodb中有一個操作菱皆，可以做查詢须误。但是理想情況下，這個lookup操作應該不會經(jīng)常使用仇轻，如果你需要經(jīng)常使用它京痢，那么你就使用了錯誤的數(shù)據(jù)存儲了（數(shù)據(jù)庫）：如果你有相關聯(lián)的數(shù)據(jù)，應該使用關系型數(shù)據(jù)庫（SQL）篷店。
因此祭椰，正規(guī)的設計應該如下
name
db.class.find( { name: '1班' } )
這樣就能查詢出自己想要的結果。
而這疲陕，就是一種單一數(shù)據(jù)查詢!畢竟你不需要去逐行匹配方淤，不涉及遍歷操作,幸運的情況下，有可能一次IO就能夠得到你想要的結果蹄殃。
因此携茂，由于關系型數(shù)據(jù)庫和非關系型數(shù)據(jù)的設計方式上的不同。導致在關系型數(shù)據(jù)中诅岩，遍歷操作比較常見讳苦，因此采用B+樹作為索引，比較合適吩谦。而在非關系型數(shù)據(jù)庫中鸳谜，單一查詢比較常見，因此采用B樹作為索引式廷，比較合適咐扭。
面試套路
目前套路有如下幾種
套路一
你簡歷寫了mysql，沒寫mongodb!面試官:"說說mysql索引結構？"我:"巴拉巴拉"面試官:"知道為什么用B+樹蝗肪，不用B樹么袜爪？"這個時候正常的面試者就蒙了，會把B樹的缺點噴一通穗慕！于是乎下一問就是面試官:"其實一些非關系型數(shù)據(jù)庫饿敲，如mongodb用的就是B樹，你知道原因么逛绵？"然后你就回去等通知了怀各！
套路二
你簡歷寫了mysql，也寫了mongodb!這種情況更完美术浪！面試官:"說說mysql索引結構瓢对？"我:"巴拉巴拉"面試官:"你簡歷寫了Mongodb，有了解過他的索引結構么胰苏？"我:"巴拉巴拉"面試官:"為什么Mongodb索引用B樹硕蛹，而Mysql用B+樹？"然后你就回去等通知了硕并！
套路三
你簡歷既沒寫mysql法焰，沒寫mongodb!面試官；"如果你來設計數(shù)據(jù)庫倔毙，你會對他的索引用什么數(shù)據(jù)結構埃仪？"我:"首先不考慮紅黑樹這類，巴拉巴拉…應該會用B樹或者B+樹陕赃。"面試官卵蛉；“如果我要設計一個像Mongodb那樣的非關系型數(shù)據(jù)庫，我要用什么數(shù)據(jù)結構當索引比較合適?”然后你就可以回去等通知了么库！
上面三個套路都是真實存在的傻丝！總之，只要面試官想問這個問題诉儒，都可以繞到這個問題上去葡缰！
