一個問題？
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的記錄：
| 5 | zhao2 | 27 |
|---|
現在我們清楚了InnoDB中主鍵索引B+樹是如何組織數據、查詢數據的，我們總結一下：
1、InnoDB存儲引擎的最小存儲單元是頁，頁可以用於存放數據也可以用於存放鍵值+指針，在B+樹中葉子節點存放數據，非葉子節點存放鍵值+指針。
2、索引組織表通過非葉子節點的二分查找法以及指針確定數據在哪個頁中，進而在去數據頁中查找到需要的數據；
那麼回到我們開始的問題，通常一棵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操作即可查找到數據。
怎麼得到InnoDB主鍵索引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 |
|---|
執行結果：
可以看出數據庫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。
最後回顧一道面試題
有一道MySQL的面試題，爲什麼MySQL的索引要使用B+樹而不是其它樹形結構?比如B樹？
現在這個問題的複雜版本可以參考本文；
他的簡單版本回答是：
因爲B樹不管葉子節點還是非葉子節點，都會保存數據，這樣導致在非葉子節點中能保存的指針數量變少（有些資料也稱爲扇出），指針少的情況下要保存大量數據，只能增加樹的高度，導致IO操作變多，查詢性能變低；
小結
本文從一個問題出發，逐步介紹了InnoDB索引組織表的原理、查詢方式，並結合已有知識，回答該問題，結合實踐來證明。當然爲了表述簡單易懂，文中忽略了一些細枝末節，比如一個頁中不可能所有空間都用於存放數據，它還會存放一些少量的其他字段比如page level，index number等等，另外還有頁的填充因子也導致一個頁不可能全部用於保存數據。關於二級索引數據存取方式可以參考MySQL相關書籍，他的要點是結合主鍵索引進行回表查詢。
參考資料：
姜承堯 《MySQL技術內幕:InnoDB存儲引擎》
姜承堯 http://www.innomysql.com/查看-innodb表中每個的索引高度/