最近看到一篇《我說(shuō) MySQL 每張表最好不要超過(guò) 2000 萬(wàn)數(shù)據(jù)，面試官讓我回去等通知》的文章，非常有趣。

文中提到，他朋友在面試的過(guò)程中說(shuō)，自己的工作就是把用戶操作信息存到 MySQL 里，因?yàn)閿?shù)據(jù)量超大（5000 萬(wàn)條左右），需要每天定時(shí)生成 3 張表，然后將數(shù)據(jù)取模分別存到這三張表里。

接下來(lái)是兩人的對(duì)話：

面試后續(xù)暫且不論，不過(guò)，互聯(lián)網(wǎng)江湖上的確流傳著一個(gè)說(shuō)法：?jiǎn)伪頂?shù)據(jù)量超過(guò) 500 萬(wàn)行時(shí)就要進(jìn)行分表分庫(kù)，已經(jīng)超過(guò) 2000 萬(wàn)行時(shí) MySQL 的性能就會(huì)急劇下降。

那么，MySQL 一張表最多能存多少數(shù)據(jù)？

今天我們就從技術(shù)層面剖析一下，MySQL 單表數(shù)據(jù)不能過(guò)大的根本原因是什么？

猜想 1，是索引深度嗎？

很多人認(rèn)為：數(shù)據(jù)量超過(guò) 500 萬(wàn)行或 2000 萬(wàn)行時(shí)，引起 B+tree 的高度增加，延長(zhǎng)了索引的搜索路徑，進(jìn)而導(dǎo)致了性能下降。事實(shí)果真如此嗎？

我們先理一下關(guān)系，MySQL 采用了索引組織表的形式組織數(shù)據(jù)，葉子節(jié)點(diǎn)存儲(chǔ)數(shù)據(jù)，非葉子節(jié)點(diǎn)存儲(chǔ)主鍵與頁(yè)面號(hào)的映射關(guān)系。若用戶的主鍵長(zhǎng)度是 8 字節(jié)時(shí)，MySQL 中頁(yè)面偏移占 4 個(gè)字節(jié)，在非葉子節(jié)點(diǎn)的時(shí)候?qū)嶋H上是 8+4=12 個(gè)字節(jié)，12 個(gè)字節(jié)表示一個(gè)頁(yè)面的映射關(guān)系。

MySQL 默認(rèn)是 16K 的頁(yè)面，拋開(kāi)它的配置 header，大概就是 15K，因此，非葉子節(jié)點(diǎn)的索引頁(yè)面可放 15*1024/12=1280 條數(shù)據(jù)，按照每行 1K 計(jì)算，每個(gè)葉子節(jié)點(diǎn)可以存 15 條數(shù)據(jù)。同理，三層就是 15*1280*1280=24576000 條數(shù)據(jù)。只有數(shù)據(jù)量達(dá)到 24576000 條時(shí)，深度才會(huì)增加為 4，所以，索引深度沒(méi)有那么容易增加，詳細(xì)數(shù)據(jù)可參考下表：

搜索路徑延長(zhǎng)導(dǎo)致性能下降的說(shuō)法，與當(dāng)時(shí)的機(jī)械硬盤和內(nèi)存條件不無(wú)關(guān)系。

之前機(jī)械硬盤的 IOPS 在 100 左右，而現(xiàn)在普遍使用的 SSD 的 IOPS 已經(jīng)過(guò)萬(wàn)，之前的內(nèi)存最大幾十 G，現(xiàn)在服務(wù)器內(nèi)存最大可達(dá)到 TB 級(jí)。

因此，即使深度增加，以目前的硬件資源，IO 也不會(huì)成為限制 MySQL 單表數(shù)據(jù)量的根本性因素。

那么，限制 MySQL 單表不能過(guò)大的根本性因素是什么？

猜想 2，是 SMO 無(wú)法并發(fā)嗎？

我們可以嘗試從 MySQL 所采用的存儲(chǔ)引擎 InnoDB 本身來(lái)探究一下。

大家知道 InnoDB 引擎使用的是索引組織表，它是通過(guò)索引來(lái)組織數(shù)據(jù)的，而它采用 B+tree 作為索引的數(shù)據(jù)結(jié)構(gòu)。B+Tree 操作非原子，所以當(dāng)一個(gè)線程做結(jié)構(gòu)調(diào)整（SMO，Struction-Modification-Operation）時(shí)一般會(huì)涉及多個(gè)節(jié)點(diǎn)的改動(dòng)。

SMO 動(dòng)作過(guò)程中，此時(shí)若有另一個(gè)線程進(jìn)來(lái)可能會(huì)訪問(wèn)到錯(cuò)誤的 B+Tree 結(jié)構(gòu)，InnoDB 為了解決這個(gè)問(wèn)題采用了樂(lè)觀鎖和悲觀鎖的并發(fā)控制協(xié)議。

InnoDB 對(duì)于葉子節(jié)點(diǎn)的修改操作如下：

方法一，先采用樂(lè)觀鎖的方式嘗試進(jìn)行修改。

對(duì)根節(jié)點(diǎn)加 S 鎖（sharedlock，叫共享鎖，也稱讀鎖），依次對(duì)非葉子節(jié)點(diǎn)加 S 鎖。

如果葉子節(jié)點(diǎn)的修改不會(huì)引起 B+Tree 結(jié)構(gòu)變動(dòng)，如分裂、合并等操作，那么只需要對(duì)葉子節(jié)點(diǎn)進(jìn)行加 X 鎖（exclusivelock，叫排他鎖，也稱為寫鎖）即可完成修改。如下圖中所示：

方式二，采用悲觀鎖的方式

如果對(duì)葉子結(jié)點(diǎn)的修改會(huì)觸發(fā) SMO，那么會(huì)采用悲觀鎖的方式。

采用悲觀鎖，需要重新遍歷 B+Tree，對(duì)根節(jié)點(diǎn)加全局 SX 鎖（SX 鎖是行鎖），然后從根節(jié)點(diǎn)到葉子節(jié)點(diǎn)可能修改的節(jié)點(diǎn)加 X 鎖）。在整個(gè) SMO 過(guò)程中，根節(jié)點(diǎn)始終持有 SX 鎖（SX 鎖表示有意向修改這個(gè)保護(hù)的范圍，SX 鎖與 SX 鎖、X 鎖沖突，與 S 鎖不沖突），此時(shí)其他的 SMO，則需要等待。

因此，InnoDB 對(duì)于簡(jiǎn)單的主鍵查詢比較快，因?yàn)閿?shù)據(jù)都存儲(chǔ)在葉子節(jié)點(diǎn)中，但對(duì)于數(shù)據(jù)量大且改操作比較多的 TP 型業(yè)務(wù)，并發(fā)會(huì)有很嚴(yán)重的瓶頸問(wèn)題。

在對(duì)葉子節(jié)點(diǎn)的修改操作中，InnoDB 可以實(shí)現(xiàn)較好的 1 與 1、1 與 2 的并發(fā)，但是無(wú)法解決 2 的并發(fā)。因?yàn)樵诜绞?2 中，根節(jié)點(diǎn)始終持有 SX 鎖，必須串行執(zhí)行，等待上一個(gè) SMO 操作完成。這樣在具有大量的 SMO 操作時(shí)，InnoDB 的 B+Tree 實(shí)現(xiàn)就會(huì)出現(xiàn)很嚴(yán)重的性能瓶頸。

解決方案

目前業(yè)界有一個(gè)更好的方案 B-LinkTree，與 B+Tree 相比，B-LinkTree 優(yōu)化了 B+Tree 結(jié)構(gòu)調(diào)整時(shí)的鎖粒度，只需要逐層加鎖，無(wú)需對(duì) root 節(jié)點(diǎn)加全局鎖，因此，可以做到在 SMO 過(guò)程中寫操作的并發(fā)執(zhí)行，保持高并發(fā)下性能的穩(wěn)定。

主要改進(jìn)點(diǎn)有 2 個(gè)：

1.中間節(jié)點(diǎn)增加 link 指針，指向右兄弟節(jié)點(diǎn)；

2.每個(gè)節(jié)點(diǎn)內(nèi)增加字段 highkey，存儲(chǔ)該節(jié)點(diǎn)中最大的 key 值。

新增的 link 指針便是為了解決 SMO 過(guò)程中并發(fā)寫的問(wèn)題，在 SMO 過(guò)程中，B-LinkTree 對(duì)修改節(jié)點(diǎn)逐層加鎖，修改完一層即可放鎖，然后去加上一層節(jié)點(diǎn)的鎖繼續(xù)修改。這樣在 InnoDB 引擎中被 SMO 阻塞的寫操作可以有機(jī)會(huì)再 SMO 操作過(guò)程中并發(fā)進(jìn)行。

如下圖所示，在節(jié)點(diǎn) 2 分裂為節(jié)點(diǎn) 2 和 4 的過(guò)程中，只需要在最后一步將父節(jié)點(diǎn) 1 指向新節(jié)點(diǎn) 4 時(shí)，對(duì)父節(jié)點(diǎn) 1 加鎖，其他操作均無(wú)需對(duì)父節(jié)點(diǎn)加鎖，更無(wú)需對(duì) root 節(jié)點(diǎn)加鎖，因此，大大提升了 SMO 過(guò)程中寫操作的并發(fā)度。

由此可見(jiàn)，和 B+Tree 全局加鎖對(duì)比起來(lái)，B-LinkTree 在高并發(fā)操作下的性能是顯著優(yōu)于 B+Tree 的。華為云 GaussDB 當(dāng)前采用的就是 B-LinkTree 索引數(shù)據(jù)結(jié)構(gòu)。

InnoDB 的索引組織表更容易觸發(fā) SMO

索引組織表的葉子節(jié)點(diǎn)，存儲(chǔ)主鍵以及應(yīng)對(duì)行的數(shù)據(jù)，InnoDB 默認(rèn)頁(yè)面為 16K，若每行數(shù)據(jù)的大小為 1000 字節(jié)，每個(gè)葉子節(jié)點(diǎn)僅能存儲(chǔ) 16 行數(shù)據(jù)。

在索引組織表中，當(dāng)葉子節(jié)點(diǎn)的扇出值過(guò)低時(shí)，SMO 的觸發(fā)將更加頻繁，進(jìn)而放大了 SMO 無(wú)法并發(fā)寫的缺陷。

目前業(yè)界有一個(gè)堆組織表的數(shù)據(jù)組織方案，也是華為云數(shù)據(jù)庫(kù) GaussDB 采用的方案。它的葉子節(jié)點(diǎn)存儲(chǔ)索引鍵以及對(duì)應(yīng)的行指針（所在的頁(yè)面編號(hào)及頁(yè)內(nèi)偏移），堆組織表葉子節(jié)點(diǎn)可以存更多的數(shù)據(jù)，分析可得在同樣的數(shù)據(jù)量與業(yè)務(wù)并發(fā)量下，堆組織表會(huì)比索引組織表發(fā)生 SMO 概率低許多。

性能對(duì)比

在 8U32G 的兩臺(tái)服務(wù)器分別搭建了 MySQL（B+Tree 和索引組織表）與 GaussDB（B-LinkTree 和堆組織表）的環(huán)境，進(jìn)行了如下性能驗(yàn)證：

實(shí)驗(yàn)場(chǎng)景：在基礎(chǔ)表的場(chǎng)景上，測(cè)試增量隨機(jī)插入性能。

1.基礎(chǔ)表總大小 10G，包含主鍵隨機(jī)分布的 1000w 行數(shù)據(jù)，每行數(shù)據(jù) 1k；

2.插入主鍵隨機(jī)分布的 1000w 行數(shù)據(jù)，每行數(shù)據(jù)大小 1k，測(cè)試并發(fā)插入性能。

結(jié)論：隨著并發(fā)數(shù)的上升，GaussDB 能穩(wěn)步提升系統(tǒng)的 TPS，而 MySQL 并發(fā)數(shù)的提高并不能帶來(lái) TPS 的顯著提升。

總結(jié)

MySQL 無(wú)法支持大數(shù)據(jù)量下并發(fā)修改的根本原因，是因?yàn)槠渌饕l(fā)控制協(xié)議的缺陷造成的，而 MySQL 選擇索引組織表，又放大了這一缺陷。所以，開(kāi)源 MySQL 數(shù)據(jù)庫(kù)更適用于主鍵查詢?yōu)橹鞯暮?jiǎn)單業(yè)務(wù)場(chǎng)景，如互聯(lián)網(wǎng)類應(yīng)用，對(duì)于復(fù)雜的商業(yè)場(chǎng)景限制比較明顯。

相比之下，采用 B-LinkTree 和堆組織表的 GaussDB 數(shù)據(jù)庫(kù)在性能和場(chǎng)景應(yīng)用方面更勝一籌。

審核編輯黃宇