面試題：InnoDB中一棵B+樹能存多少行數據？

閱讀本文大概須要 5 分鐘。

做者：李平 | 來源：我的博客

1、InnoDB 一棵 B+ 樹能夠存放多少行數據？

InnoDB 一棵 B+ 樹能夠存放多少行數據？

這個問題的簡單回答是：約 2 千萬。

爲何是這麼多呢？

由於這是能夠算出來的，要搞清楚這個問題，咱們先從 InnoDB 索引數據結構、數據組織方式提及。

咱們都知道計算機在存儲數據的時候，有最小存儲單元，這就比如咱們今天進行現金的流通最小單位是一毛。

在計算機中磁盤存儲數據最小單元是扇區，一個扇區的大小是 512 字節，而文件系統（例如XFS/EXT4）他的最小單元是塊，一個塊的大小是 4k，而對於咱們的 InnoDB 存儲引擎也有本身的最小儲存單元——頁（Page），一個頁的大小是 16K。

2、下面幾張圖能夠幫你理解最小存儲單元

文件系統中一個文件大小隻有1個字節，但不得不佔磁盤上4KB的空間。

Innodb 的全部數據文件（後綴爲 ibd 的文件），他的大小始終都是 16384（16k）的整數倍。

磁盤扇區、文件系統、InnoDB 存儲引擎都有各自的最小存儲單元。

在 MySQL 中咱們的 InnoDB 頁的大小默認是 16k，固然也能夠經過參數設置：

數據表中的數據都是存儲在頁中的，因此一個頁中能存儲多少行數據呢？

假設一行數據的大小是 1k，那麼一個頁能夠存放 16 行這樣的數據。

若是數據庫只按這樣的方式存儲，那麼如何查找數據就成爲一個問題，由於咱們不知道要查找的數據存在哪一個頁中，也不可能把全部的頁遍歷一遍，那樣太慢了。

因此人們想了一個辦法，用 B+ 樹的方式組織這些數據。如圖所示：

咱們先將數據記錄按主鍵進行排序，分別存放在不一樣的頁中（爲了便於理解咱們這裏一個頁中只存放 3 條記錄，實際狀況能夠存放不少），除了存放數據的頁之外，還有存放鍵值+指針的頁，如圖中page number=3 的頁，該頁存放鍵值和指向數據頁的指針，這樣的頁由 N 個鍵值 + 指針組成。

固然它也是排好序的。

這樣的數據組織形式，咱們稱爲索引組織表。

如今來看下，要查找一條數據，怎麼查？

如 select * from user where id=5;

這裏 id 是主鍵，咱們經過這棵 B+ 樹來查找，首先找到根頁，你怎麼知道 user 表的根頁在哪呢？

其實每張表的根頁位置在表空間文件中是固定的，即 page number=3 的頁（這點咱們下文還會進一步證實），找到根頁後經過二分查找法，定位到 id=5 的數據應該在指針 P5 指向的頁中，那麼進一步去 page number=5 的頁中查找，一樣經過二分查詢法便可找到 id=5 的記錄：

| 5 | zhao2 | 27 |

如今咱們清楚了 InnoDB 中主鍵索引 B+ 樹是如何組織數據、查詢數據的，咱們總結一下：

一、InnoDB 存儲引擎的最小存儲單元是頁，頁能夠用於存放數據也能夠用於存放鍵值 + 指針，在 B+ 樹中葉子節點存放數據，非葉子節點存放鍵值 + 指針。

二、索引組織表經過非葉子節點的二分查找法以及指針肯定數據在哪一個頁中，進而在去數據頁中查找到須要的數據；

3、那麼回到咱們開始的問題，一般一棵 B+ 樹能夠存放多少行數據？

這裏咱們先假設 B+ 樹高爲 2，即存在一個根節點和若干個葉子節點，那麼這棵 B+ 樹的存放總記錄數爲：根節點指針數 * 單個葉子節點記錄行數。

上文咱們已經說明單個葉子節點（頁）中的記錄數 =16K/1K=16。（這裏假設一行記錄的數據大小爲 1k，實際上如今不少互聯網業務數據記錄大小一般就是 1K 左右）。

那麼如今咱們須要計算出非葉子節點能存放多少指針？

其實這也很好算，咱們假設主鍵 ID 爲 bigint 類型，長度爲 8 字節，而指針大小在 InnoDB 源碼中設置爲 6 字節，這樣一共 14 字節，咱們一個頁中能存放多少這樣的單元，其實就表明有多少指針，即 16384/14=1170。

那麼能夠算出一棵高度爲 2 的 B+ 樹，能存放 1170*16=18720 條這樣的數據記錄。

根據一樣的原理咱們能夠算出一個高度爲 3 的 B+ 樹能夠存放： 1170*1170*16=21902400 條這樣的記錄。

因此在 InnoDB 中 B+ 樹高度通常爲 1-3 層，它就能知足千萬級的數據存儲。

在查找數據時一次頁的查找表明一次 IO，因此經過主鍵索引查詢一般只須要 1-3 次 IO 操做便可查找到數據。

4、怎麼獲得 InnoDB 主鍵索引 B+ 樹的高度？

上面咱們經過推斷得出 B+ 樹的高度一般是 1-3，下面咱們從另一個側面證實這個結論。

在 InnoDB 的表空間文件中，約定 page numbe r爲 3 的表明主鍵索引的根頁，而在根頁偏移量爲 64 的地方存放了該 B+ 樹的 page level。

若是 page level 爲 1，樹高爲 2，page level 爲 2，則樹高爲 3。

即 B+ 樹的高度 =page level+1；

下面咱們將從實際環境中嘗試找到這個 page level。

在實際操做以前，你能夠經過 InnoDB 元數據表確認主鍵索引根頁的 page number 爲 3，你也能夠從《InnoDB 存儲引擎》這本書中獲得確認。

執行結果：

能夠看出數據庫 dbt3 下的 customer 表、lineitem 表主鍵索引根頁的 page number 均爲 3，而其餘的二級索引 page number 爲 4。

關於二級索引與主鍵索引的區別請參考 MySQL 相關書籍，本文不在此介紹。

下面咱們對數據庫表空間文件作想相關的解析：

由於主鍵索引 B+ 樹的根頁在整個表空間文件中的第 3 個頁開始，因此能夠算出它在文件中的偏移量：16384*3=49152（16384 爲頁大小）。

另外根據《InnoDB 存儲引擎》中描述在根頁的 64 偏移量位置前 2 個字節，保存了 page level 的值，所以咱們想要的 page level 的值在整個文件中的偏移量爲：16384*3+64=49152+64=49216，前 2 個字節中。

接下來咱們用 hexdump 工具，查看錶空間文件指定偏移量上的數據：

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；

這三張表的數據量以下：

5、小結

lineitem 表的數據行數爲 600 多萬，B+ 樹高度爲 3，customer 表數據行數只有 15 萬，B+ 樹高度也爲 3。

能夠看出儘管數據量差別較大，這兩個表樹的高度都是 3，換句話說這兩個表經過索引查詢效率並無太大差別，由於都只須要作 3 次 IO。

那麼若是有一張錶行數是一千萬，那麼他的 B+ 樹高度依舊是 3，查詢效率仍然不會相差太大。

region 表只有 5 行數據，固然他的 B+ 樹高度爲 1。

6、最後回顧一道面試題

有一道 MySQL 的面試題，爲何 MySQL 的索引要使用 B+ 樹而不是其它樹形結構？

好比 B 樹？

如今這個問題的複雜版本能夠參考本文；

他的簡單版本回答是：

由於 B 樹無論葉子節點仍是非葉子節點，都會保存數據，這樣致使在非葉子節點中能保存的指針數量變少（有些資料也稱爲扇出），指針少的狀況下要保存大量數據，只能增長樹的高度，致使 IO 操做變多，查詢性能變低。

7、總結

本文從一個問題出發，逐步介紹了 InnoDB 索引組織表的原理、查詢方式，並結合已有知識，回答該問題，結合實踐來證實。

固然爲了表述簡單易懂，文中忽略了一些細枝末節，好比一個頁中不可能全部空間都用於存放數據，它還會存放一些少許的其餘字段好比 page level，index number 等等，另外還有頁的填充因子也致使一個頁不可能所有用於保存數據。

關於二級索引數據存取方式能夠參考 MySQL 相關書籍，他的要點是結合主鍵索引進行回表查詢。

·END·

程序員的成長之路

路雖遠，行則必至

本文原發於 同名微信公衆號「程序員的成長之路」，回覆「1024」你懂得，給個讚唄。

回覆 [ 520 ] 領取程序員最佳學習方式

回覆 [ 256 ] 查看 Java 程序員成長規劃

往期精彩回顧

JSON WEB TOKEN 從原理到實戰

很全！淺談幾種經常使用負載均衡架構

Elasticsearch如何作到億級數據查詢毫秒級返回？

Redis 到底能解決哪些問題

如何發現 Redis 熱點 Key ，解決方案有哪些？

【漫畫】程序員系列蘇大強版表情包

揭祕 「全網影視 VIP 卡」 的背後產業鏈