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

1.一個問題

InnoDB一棵B+樹能夠存放多少行數據？這個問題的簡單回答是：約2千萬。爲何是這麼多呢？由於這是能夠算出來的，要搞清楚這個問題，咱們先從InnoDB索引數據結構、數據組織方式提及。 咱們都知道計算機在存儲數據的時候，有最小存儲單元，這就比如咱們今天進行現金的流通最小單位是一毛。在計算機中磁盤存儲數據最小單元是扇區，一個扇區的大小是512字節，而文件系統（例如XFS/EXT4）他的最小單元是塊，一個塊的大小是4k，而對於咱們的InnoDB存儲引擎也有本身的最小儲存單元——頁（Page），一個頁的大小是16K。 下面幾張圖能夠幫你理解最小存儲單元： 文件系統中一個文件大小隻有1個字節，但不得不佔磁盤上4KB的空間。 innodb的全部數據文件（後綴爲ibd的文件），他的大小始終都是16384（16k）的整數倍。 磁盤扇區、文件系統、InnoDB存儲引擎都有各自的最小存儲單元。 在MySQL中咱們的InnoDB頁的大小默認是16k，固然也能夠經過參數設置：

mysql> show variables like 'innodb_page_size';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| innodb_page_size | 16384 |
+------------------+-------+
1 row in set (0.00 sec)

數據表中的數據都是存儲在頁中的，因此一個頁中能存儲多少行數據呢？假設一行數據的大小是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的記錄： 中，那麼進一步去page number=5的頁中查找，一樣經過二分查詢法便可找到id=5的記錄：

5|zhao2|27

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

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

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

那麼回到咱們開始的問題，一般一棵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+樹能夠存放：1170117016=21902400條這樣的記錄。因此在InnoDB中B+樹高度通常爲1-3層，它就能知足千萬級的數據存儲。在查找數據時一次頁的查找表明一次IO，因此經過主鍵索引查詢一般只須要1-3次IO操做便可查找到數據。

2. 怎麼獲得B+樹的高度？

上面咱們經過推斷得出B+樹的高度一般是1-3，下面咱們從另一個側面證實這個結論。在InnoDB的表空間文件中，約定page number爲3的表明主鍵索引的根頁，而在根頁偏移量爲64的地方存放了該B+樹的page level。若是page level爲1，樹高爲2，page level爲2，則樹高爲3。即B+樹的高度=page level+1；下面咱們將從實際環境中嘗試找到這個page level。

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

SELECT
b.name, a.name, index_id, type, a.space, a.PAGE_NO
FROM
information_schema.INNODB_SYS_INDEXES a,
information_schema.INNODB_SYS_TABLES b
WHERE
a.table_id = b.table_id AND a.space <> 0;

執行結果： 能夠看出數據庫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；

這三張表的數據量以下： 總結：

lineitem表的數據行數爲600多萬，B+樹高度爲3，customer表數據行數只有15萬，B+樹高度也爲3。能夠看出儘管數據量差別較大，這兩個表樹的高度都是3，換句話說這兩個表經過索引查詢效率並無太大差別，由於都只須要作3次IO。那麼若是有一張錶行數是一千萬，那麼他的B+樹高度依舊是3，查詢效率仍然不會相差太大。

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

3. 小結

本文從一個問題出發，逐步介紹了InnoDB索引組織表的原理、查詢方式，並結合已有知識，回答該問題，結合實踐來證實。固然爲了表述簡單易懂，文中忽略了一些細枝末節，好比一個頁中不可能全部空間都用於存放數據，它還會存放一些少許的其餘字段好比page level，index number等等，另外還有頁的填充因子也致使一個頁不可能所有用於保存數據。關於二級索引數據存取方式能夠參考MySQL相關書籍，他的要點是結合主鍵索引進行回表查詢。

來源：cnblogs.com/leefreeman/p/8315844.html
整編：二師兄
關注微信公衆號【悟能之能】瞭解更多編程技巧。