一、Mysql為什么只能支持2000w左右的數據量

簡而言之，是B+樹的層數問題。

假設表中一行記錄的數據大小為1k(實際上現在很多互聯網業務數據記錄大小通常就是1K左右)

所以(主鍵索引中)葉子節點的一個節點(即一個page,且為數據頁),在這里認為可以放16行記錄.

假設主鍵ID為bigint類型(長度為8字節)，而指針大小在InnoDB源碼中是6字節，這樣一共14字節，我們一個頁(Page,在此為目錄頁)中能存放多少這樣的(索引)單元，其實就代表有多少指針，即16384/14=1170。即一個目錄Page,能存大概1170個(索引)單元.

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

根據同樣原理, 可以算出一個高度為3的B+樹可以存放：1170*1170*16=21902400條這樣的記錄。

所以在InnoDB中B+樹高度一般為1-3層，就能滿足千萬級的數據存儲。在查找數據時一次頁的查找代表一次磁盤IO，所以通過主鍵索引查詢通常只需要1-3次IO操作即可查找到數據。

所以如果 表A的數據行數為600多萬，B+樹高度為3；表B的數據行數只有15萬，B+樹高度也為3。可以看出盡管數據量差異較大，這兩個表樹的高度都是3，換句話說這兩個表通過索引查詢效率并沒有太大差異，因為都只需要做3次IO。如果有一張表行數是一千萬，那么其B+樹高度依舊是3，查詢效率仍然不會相差太大。

當然如果一張表只有5行數據，那么它的B+樹高度為1。

即當數據量在18720到21902400行之間時,B+樹的高度都是3,查詢的速度幾乎相同.

因為二分查找是在內存里邊進行的,速度很快.和磁盤IO差幾個數量級,可以忽略. 那么即從2萬行記錄到2200萬行記錄,主體的查詢性能差不多。

延伸閱讀：

二、數據庫的查詢功能實現原理

數據庫查詢是數據庫的最主要功能之一。我們都希望查詢數據的速度能盡可能的快，因此數據庫系統的設計者會從查詢算法的角度進行優化。最基本的查詢算法當然是順序查找（linear search），這種復雜度為O(n)的算法在數據量很大時顯然是糟糕的，好在計算機科學的發展提供了很多更優異的查找算法，例如二分查找（binary search）、二叉樹查找（binary tree search）等。如果稍微分析一下會發現，每種查找算法都只能應用于特定的數據結構之上，例如二分查找要求被檢索數據有序，而二叉樹查找只能應用于二叉查找樹上，但是數據本身的組織結構不可能完全滿足各種數據結構（例如，理論上不可能同時將兩列都按順序進行組織），所以，在數據之外，數據庫系統還維護著滿足特定查找算法的數據結構，這些數據結構以某種方式引用（指向）數據，這樣就可以在這些數據結構上實現高級查找算法。這種數據結構，就是索引。