一、Mysql為什么只能支持2000w左右的數(shù)據(jù)量

簡而言之，是B+樹的層數(shù)問題。

假設(shè)表中一行記錄的數(shù)據(jù)大小為1k(實際上現(xiàn)在很多互聯(lián)網(wǎng)業(yè)務數(shù)據(jù)記錄大小通常就是1K左右)

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

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

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

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

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

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

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

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

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

延伸閱讀：

二、數(shù)據(jù)庫的查詢功能實現(xiàn)原理

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