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

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

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

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

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

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

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

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

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

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

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

因?yàn)槎植檎沂窃趦?nèi)存里邊進(jìn)行的,速度很快.和磁盤IO差幾個(gè)數(shù)量級(jí),可以忽略. 那么即從2萬(wàn)行記錄到2200萬(wàn)行記錄,主體的查詢性能差不多。

延伸閱讀：

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

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