為什么 MySQL 索引要使用 B+樹而不是其它樹形結(jié)構(gòu)焰络?比如 B 樹?

來源:https://www.cnblogs.com/leefreeman/p/8315844.html?from=singlemessage&isappinstalled=0

一個問題符喝?

InnoDB一棵B+樹可以存放多少行數(shù)據(jù)闪彼?這個問題的簡單回答是:約2千萬

為什么是這么多呢?

因為這是可以算出來的,要搞清楚這個問題畏腕,我們先從InnoDB索引數(shù)據(jù)結(jié)構(gòu)缴川、數(shù)據(jù)組織方式說起。

我們都知道計算機(jī)在存儲數(shù)據(jù)的時候描馅,有最小存儲單元把夸,這就好比我們今天進(jìn)行現(xiàn)金的流通最小單位是一毛。

在計算機(jī)中磁盤存儲數(shù)據(jù)最小單元是扇區(qū)铭污,一個扇區(qū)的大小是512字節(jié)恋日,而文件系統(tǒng)(例如XFS/EXT4)他的最小單元是塊,一個塊的大小是4k

而對于我們的InnoDB存儲引擎也有自己的最小儲存單元——頁(Page)嘹狞,一個頁的大小是16K岂膳。

下面幾張圖可以幫你理解最小存儲單元:

文件系統(tǒng)中一個文件大小只有1個字節(jié),但不得不占磁盤上4KB的空間磅网。

image

innodb的所有數(shù)據(jù)文件(后綴為ibd的文件)谈截,他的大小始終都是16384(16k)的整數(shù)倍。

image

磁盤扇區(qū)知市、文件系統(tǒng)傻盟、InnoDB存儲引擎都有各自的最小存儲單元。

image

在MySQL中我們的InnoDB頁的大小默認(rèn)是16k嫂丙,當(dāng)然也可以通過參數(shù)設(shè)置:

image

數(shù)據(jù)表中的數(shù)據(jù)都是存儲在頁中的,所以一個頁中能存儲多少行數(shù)據(jù)呢规哲?假設(shè)一行數(shù)據(jù)的大小是1k跟啤,那么一個頁可以存放16行這樣的數(shù)據(jù)。

如果數(shù)據(jù)庫只按這樣的方式存儲唉锌,那么如何查找數(shù)據(jù)就成為一個問題

因為我們不知道要查找的數(shù)據(jù)存在哪個頁中隅肥,也不可能把所有的頁遍歷一遍,那樣太慢了袄简。

所以人們想了一個辦法腥放,用B+樹的方式組織這些數(shù)據(jù)。如圖所示:

image

我們先將數(shù)據(jù)記錄按主鍵進(jìn)行排序绿语,分別存放在不同的頁中(為了便于理解我們這里一個頁中只存放3條記錄秃症,實際情況可以存放很多)

除了存放數(shù)據(jù)的頁以外,還有存放鍵值+指針的頁吕粹,如圖中page number=3的頁种柑,該頁存放鍵值和指向數(shù)據(jù)頁的指針,這樣的頁由N個鍵值+指針組成匹耕。

當(dāng)然它也是排好序的聚请。這樣的數(shù)據(jù)組織形式,我們稱為索引組織表稳其。

現(xiàn)在來看下驶赏,要查找一條數(shù)據(jù)炸卑,怎么查?

如:select * from user where id=5;

這里id是主鍵,我們通過這棵B+樹來查找煤傍,首先找到根頁矾兜,你怎么知道user表的根頁在哪呢?

其實每張表的根頁位置在表空間文件中是固定的患久,即page number=3的頁(這點我們下文還會進(jìn)一步證明)

找到根頁后通過二分查找法椅寺,定位到id=5的數(shù)據(jù)應(yīng)該在指針P5指向的頁中,那么進(jìn)一步去page number=5的頁中查找蒋失,同樣通過二分查詢法即可找到id=5的記錄:

5 zhao2 27

現(xiàn)在我們清楚了InnoDB中主鍵索引B+樹是如何組織數(shù)據(jù)返帕、查詢數(shù)據(jù)的,我們總結(jié)一下:

1篙挽、InnoDB存儲引擎的最小存儲單元是頁荆萤,頁可以用于存放數(shù)據(jù)也可以用于存放鍵值+指針,在B+樹中葉子節(jié)點存放數(shù)據(jù)铣卡,非葉子節(jié)點存放鍵值+指針链韭。

2、索引組織表通過非葉子節(jié)點的二分查找法以及指針確定數(shù)據(jù)在哪個頁中煮落,進(jìn)而在去數(shù)據(jù)頁中查找到需要的數(shù)據(jù)敞峭;

那么回到我們開始的問題,通常一棵B+樹可以存放多少行數(shù)據(jù)蝉仇?

這里我們先假設(shè)B+樹高為2旋讹,即存在一個根節(jié)點和若干個葉子節(jié)點,那么這棵B+樹的存放總記錄數(shù)為:根節(jié)點指針數(shù)*單個葉子節(jié)點記錄行數(shù)轿衔。

上文我們已經(jīng)說明單個葉子節(jié)點(頁)中的記錄數(shù)=16K/1K=16沉迹。(這里假設(shè)一行記錄的數(shù)據(jù)大小為1k,實際上現(xiàn)在很多互聯(lián)網(wǎng)業(yè)務(wù)數(shù)據(jù)記錄大小通常就是1K左右)害驹。

那么現(xiàn)在我們需要計算出非葉子節(jié)點能存放多少指針鞭呕?

其實這也很好算,我們假設(shè)主鍵ID為bigint類型宛官,長度為8字節(jié)葫松,而指針大小在InnoDB源碼中設(shè)置為6字節(jié),這樣一共14字節(jié)

我們一個頁中能存放多少這樣的單元摘刑,其實就代表有多少指針进宝,即16384/14=1170。

那么可以算出一棵高度為2的B+樹枷恕,能存放1170*16=18720條這樣的數(shù)據(jù)記錄党晋。

根據(jù)同樣的原理我們可以算出一個高度為3的B+樹可以存放:1170117016=21902400條這樣的記錄。

所以在InnoDB中B+樹高度一般為1-3層,它就能滿足千萬級的數(shù)據(jù)存儲未玻。

在查找數(shù)據(jù)時一次頁的查找代表一次IO灾而,所以通過主鍵索引查詢通常只需要1-3次IO操作即可查找到數(shù)據(jù)。

怎么得到InnoDB主鍵索引B+樹的高度扳剿?

上面我們通過推斷得出B+樹的高度通常是1-3旁趟,下面我們從另外一個側(cè)面證明這個結(jié)論。

在InnoDB的表空間文件中庇绽,約定page number為3的代表主鍵索引的根頁锡搜,而在根頁偏移量為64的地方存放了該B+樹的page level。

如果page level為1瞧掺,樹高為2耕餐,page level為2,則樹高為3辟狈。即B+樹的高度=page level+1肠缔;下面我們將從實際環(huán)境中嘗試找到這個page level。

在實際操作之前哼转,你可以通過InnoDB元數(shù)據(jù)表確認(rèn)主鍵索引根頁的page number為3明未,你也可以從《InnoDB存儲引擎》這本書中得到確認(rèn)。

image
image

可以看出數(shù)據(jù)庫dbt3下的customer表壹蔓、lineitem表主鍵索引根頁的page number均為3趟妥,而其他的二級索引page number為4。

關(guān)于二級索引與主鍵索引的區(qū)別請參考MySQL相關(guān)書籍庶溶,本文不在此介紹煮纵。

下面我們對數(shù)據(jù)庫表空間文件做想相關(guān)的解析:

image

因為主鍵索引B+樹的根頁在整個表空間文件中的第3個頁開始,所以可以算出它在文件中的偏移量:16384*3=49152(16384為頁大衅荨)。

另外根據(jù)《InnoDB存儲引擎》中描述在根頁的64偏移量位置前2個字節(jié)匆光,保存了page level的值

因此我們想要的page level的值在整個文件中的偏移量為:16384*3+64=49152+64=49216套像,前2個字節(jié)中。

接下來我們用hexdump工具终息,查看表空間文件指定偏移量上的數(shù)據(jù):

image

linetem表的page level為2夺巩,B+樹高度為page level+1=3;

region表的page level為0周崭,B+樹高度為page level+1=1柳譬;

customer表的page level為2,B+樹高度為page level+1=3续镇;

這三張表的數(shù)據(jù)量如下:

image

總結(jié):

lineitem表的數(shù)據(jù)行數(shù)為600多萬美澳,B+樹高度為3,customer表數(shù)據(jù)行數(shù)只有15萬,B+樹高度也為3制跟【俗可以看出盡管數(shù)據(jù)量差異較大,這兩個表樹的高度都是3

換句話說這兩個表通過索引查詢效率并沒有太大差異雨膨,因為都只需要做3次IO擂涛。那么如果有一張表行數(shù)是一千萬,那么他的B+樹高度依舊是3聊记,查詢效率仍然不會相差太大撒妈。

region表只有5行數(shù)據(jù),當(dāng)然他的B+樹高度為1排监。

最后回顧一道面試題

有一道MySQL的面試題狰右,為什么MySQL的索引要使用B+樹而不是其它樹形結(jié)構(gòu)?比如B樹?

現(xiàn)在這個問題的復(fù)雜版本可以參考本文社露;

他的簡單版本回答是:

因為B樹不管葉子節(jié)點還是非葉子節(jié)點挟阻,都會保存數(shù)據(jù),這樣導(dǎo)致在非葉子節(jié)點中能保存的指針數(shù)量變少(有些資料也稱為扇出)

指針少的情況下要保存大量數(shù)據(jù)峭弟,只能增加樹的高度附鸽,導(dǎo)致IO操作變多,查詢性能變低瞒瘸;

小結(jié)

本文從一個問題出發(fā)坷备,逐步介紹了InnoDB索引組織表的原理、查詢方式情臭,并結(jié)合已有知識省撑,回答該問題,結(jié)合實踐來證明俯在。

當(dāng)然為了表述簡單易懂竟秫,文中忽略了一些細(xì)枝末節(jié),比如一個頁中不可能所有空間都用于存放數(shù)據(jù)跷乐,它還會存放一些少量的其他字段比如page level肥败,index number等等,另外還有頁的填充因子也導(dǎo)致一個頁不可能全部用于保存數(shù)據(jù)愕提。

關(guān)于二級索引數(shù)據(jù)存取方式可以參考MySQL相關(guān)書籍馒稍,他的要點是結(jié)合主鍵索引進(jìn)行回表查詢。

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末浅侨,一起剝皮案震驚了整個濱河市纽谒,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌如输,老刑警劉巖鼓黔,帶你破解...
    沈念sama閱讀 222,000評論 6 515
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件央勒,死亡現(xiàn)場離奇詭異,居然都是意外死亡请祖,警方通過查閱死者的電腦和手機(jī)订歪,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 94,745評論 3 399
  • 文/潘曉璐 我一進(jìn)店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來肆捕,“玉大人刷晋,你說我怎么就攤上這事∩髁辏” “怎么了眼虱?”我有些...
    開封第一講書人閱讀 168,561評論 0 360
  • 文/不壞的土叔 我叫張陵,是天一觀的道長席纽。 經(jīng)常有香客問我捏悬,道長,這世上最難降的妖魔是什么润梯? 我笑而不...
    開封第一講書人閱讀 59,782評論 1 298
  • 正文 為了忘掉前任过牙,我火速辦了婚禮,結(jié)果婚禮上纺铭,老公的妹妹穿的比我還像新娘寇钉。我一直安慰自己,他們只是感情好舶赔,可當(dāng)我...
    茶點故事閱讀 68,798評論 6 397
  • 文/花漫 我一把揭開白布扫倡。 她就那樣靜靜地躺著,像睡著了一般竟纳。 火紅的嫁衣襯著肌膚如雪撵溃。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 52,394評論 1 310
  • 那天锥累,我揣著相機(jī)與錄音缘挑,去河邊找鬼。 笑死桶略,一個胖子當(dāng)著我的面吹牛卖哎,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播删性,決...
    沈念sama閱讀 40,952評論 3 421
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼焕窝!你這毒婦竟也來了蹬挺?” 一聲冷哼從身側(cè)響起,我...
    開封第一講書人閱讀 39,852評論 0 276
  • 序言:老撾萬榮一對情侶失蹤它掂,失蹤者是張志新(化名)和其女友劉穎巴帮,沒想到半個月后溯泣,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 46,409評論 1 318
  • 正文 獨居荒郊野嶺守林人離奇死亡榕茧,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 38,483評論 3 341
  • 正文 我和宋清朗相戀三年垃沦,在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片用押。...
    茶點故事閱讀 40,615評論 1 352
  • 序言:一個原本活蹦亂跳的男人離奇死亡肢簿,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出蜻拨,到底是詐尸還是另有隱情池充,我是刑警寧澤,帶...
    沈念sama閱讀 36,303評論 5 350
  • 正文 年R本政府宣布缎讼,位于F島的核電站收夸,受9級特大地震影響,放射性物質(zhì)發(fā)生泄漏血崭。R本人自食惡果不足惜卧惜,卻給世界環(huán)境...
    茶點故事閱讀 41,979評論 3 334
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望夹纫。 院中可真熱鬧咽瓷,春花似錦、人聲如沸捷凄。這莊子的主人今日做“春日...
    開封第一講書人閱讀 32,470評論 0 24
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽跺涤。三九已至匈睁,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間桶错,已是汗流浹背航唆。 一陣腳步聲響...
    開封第一講書人閱讀 33,571評論 1 272
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機(jī)就差點兒被人妖公主榨干…… 1. 我叫王不留院刁,地道東北人糯钙。 一個月前我還...
    沈念sama閱讀 49,041評論 3 377
  • 正文 我出身青樓,卻偏偏與公主長得像退腥,于是被迫代替她去往敵國和親任岸。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當(dāng)晚...
    茶點故事閱讀 45,630評論 2 359