以mysql innodb引擎為例，innodb引擎定制化的頁大小默認為16K
我們可以通過命令查詢
SHOW VARIABLES LIKE 'innodb_page_size';
這個innodb_page_size=16384字節=16KB，就是innodb中最小的存儲單位。
假設我們一條數據是1K大小，理想情況下innodb中的一頁能存16條數據（實際能用于存儲數據的不足16K），數據庫中的每條記錄都是以頁的組織方式進行管理的。
通常來說我們還會使用主鍵對單表進行排序，而主鍵索引對應的B+Tree數據結構大概長這樣：
B+Tree由非葉子節點和葉子節點組成，非葉子節點不存儲實際數據，只存儲主鍵列+索引號（其實就是頁號）；葉子節點存儲實際的數據，且前后節點之間還會雙向關聯。
由于每個非葉子節點能存儲的索引記錄很多，樹整體的高度就矮，高度矮意味著調用磁盤IO的次數少，畢竟磁盤查詢一次10ms的開銷是非常昂貴的。
B+Tree的數據存儲量
當我們有一張按主鍵排序的單表，主鍵為BIGINT（業務最常用），且假設一條記錄1KB，innodb引擎默認頁16KB
設
- B+Tree的高度為H
- 非葉子節點每頁能存儲的索引量為I
- 葉子節點的每頁能存儲的數據量為Y
- B+Tree能存儲的數據總量為N（最底層葉子節點層）
我們知道：數據總量 N = (I ^ (H-1)) * Y
其中，Y就按最理想的16條來算（實際更少）。
且由于BIGINT字段占8個字節，innodb索引號（頁號）通常設為4字節，兩者加起來12字節，就能算出
每頁索引存儲量 I = 16 * 1024 / (8+4) = 1365
套入公式，可以得到：
- 如果B+Tree的高度為2
N = (1365^(2-1))*16 = 21840
- 如果B+Tree的高度為3
N = (1365^(3-1))*16 = 29811600，2980w條記錄——28G
- 如果B+Tree的高度為4
N = (1365^(4-1))*16 = 40692834000，406億條記錄——38T
當然，以上的數據總量N是最大理想情況，實際存儲量肯定更小。
再者，按業務常見的100qps并發請求為例，查詢表記錄的IO次數取決于樹的高度H，當H=3，一次db查詢可能耗時10ms*3=30ms，那一塊磁盤能支撐的qps = 1000 / 30 = 33，如果高峰期所有請求同時都打到這個磁盤上，那么磁盤就已經滿負荷了，最后一條記錄的延遲至少有66 * 30ms = 20s。
當H=4情況會更加糟糕，且存滿數據時，單機的磁盤也無法負載。
因此，通常情況下H=3是一個沒得選的選擇，當然，實際情況需要我們根據業務qps，單條記錄平均大小，主鍵類型，數據庫規格，操作系統配置等多個因素綜合考量單表存儲的數據上限。
