或許我們都被分庫(kù)分表約束了思維

作者：張俊杰

概述

這篇文章沒(méi)什么太多的干貨，純純是一篇討論和思考帖。

從業(yè)數(shù)據(jù)庫(kù)領(lǐng)域三年有余了，從分庫(kù)分表中間件到數(shù)據(jù)庫(kù)團(tuán)隊(duì)內(nèi)核學(xué)到了很多東西。也接觸了很多項(xiàng)目，包括TiDB、Vitess、Polardb、StarDB等等。

國(guó)內(nèi)的項(xiàng)目好像很多都聚焦于分庫(kù)分表的概念，包括很多的數(shù)據(jù)庫(kù)團(tuán)隊(duì)都在嘗試這個(gè)概念的落地和沉溺于性能的跑分。

最近我在預(yù)覽MySQL官方，看到了Partitioning的概念，而且占據(jù)了很大的篇幅。不由得引人思考，為什么這個(gè)概念在我接觸的業(yè)務(wù)中沒(méi)有被廣泛的使用呢？或許我們將來(lái)可以有分庫(kù)分區(qū)的概念？

接下來(lái)從頭縷一下數(shù)據(jù)庫(kù)選型的問(wèn)題吧（以下均以MySQL的Innodb場(chǎng)景為例）：

分表、分區(qū)、分庫(kù)有什么用處

在那個(gè)遠(yuǎn)古的時(shí)代，物理機(jī)器的配置很低，當(dāng)數(shù)據(jù)量增大的時(shí)候，傳統(tǒng)的B+樹(shù)的高度會(huì)越來(lái)越高，我們對(duì)硬件資源的要求很高，機(jī)器往往內(nèi)存爆倉(cāng)、IO打滿等等。

這導(dǎo)致：

查詢(xún)速度顯著下降。復(fù)雜的查詢(xún)、索引失效、全表掃描等操作變得緩慢。

在大表中創(chuàng)建和維護(hù)索引可能會(huì)消耗大量的時(shí)間和資源。插入、更新和刪除操作可能需要花費(fèi)更長(zhǎng)的時(shí)間來(lái)維護(hù)索引，導(dǎo)致性能下降。

讀寫(xiě)操作可能導(dǎo)致鎖沖突，降低系統(tǒng)的并發(fā)處理能力，甚至引發(fā)死鎖問(wèn)題。

備份、恢復(fù)、數(shù)據(jù)清理、空間管理等操作變得困難，維護(hù)成本和風(fēng)險(xiǎn)增加。

等等。。

后來(lái)我們引出了第一個(gè)概念：分表

分表

在 5.1版本以前，MySQL并沒(méi)有分區(qū)的概念，為了解決這個(gè)問(wèn)題，無(wú)非是單表拆成雙表、多表之類(lèi)的，這樣將一個(gè)表要面臨的問(wèn)題分散成了兩個(gè)表或者多個(gè)表共同承受。

反思當(dāng)下，在當(dāng)前這個(gè)物理資源冗余的時(shí)代，大部分業(yè)務(wù)場(chǎng)景下我們的單表真的會(huì)比分表的性能差很多嗎？有多少時(shí)候我們是為了分表而分表？我們的分表邏輯或許需要我們支持更多的功能，比如彈性、事務(wù)、一些查詢(xún)語(yǔ)句的改寫(xiě)，然后一遍一遍的造輪子給運(yùn)維帶來(lái)無(wú)盡的痛苦。

分庫(kù)

分表的解決能力還是有限的，我們一臺(tái)物理機(jī)器的能力也是有限的，這時(shí)候或許我們可以采用分表的形式，來(lái)避免熱點(diǎn)問(wèn)題或者單機(jī)器壓力過(guò)載的問(wèn)題。

將一個(gè)庫(kù)要面臨的問(wèn)題分散成了兩個(gè)庫(kù)或者多個(gè)庫(kù)共同承受。

分區(qū)

?相關(guān)文檔

在5.1版本以后MySQL出了一個(gè)國(guó)內(nèi)幾乎無(wú)人問(wèn)津的分區(qū)表的功能。

分區(qū)表的實(shí)現(xiàn)原理其實(shí)和分表差不太多，不過(guò)它更靠近文件系統(tǒng)，而沒(méi)有經(jīng)過(guò)MySQL的應(yīng)用層或者引擎層。MySQL的物理數(shù)據(jù)，存儲(chǔ)在表空間文件（.ibdata1和.ibd）中，這里講的分區(qū)的意思是指將同一表中不同行的記錄分配到不同的物理文件中，幾個(gè)分區(qū)就有幾個(gè).idb文件。

隨著 MySQL 版本的更新迭代，分區(qū)功能也在后續(xù)版本中不斷得到改進(jìn)和增強(qiáng)。具體的分區(qū)功能支持情況如下：

?MySQL 5.1：引入了 Range 和 List 兩種分區(qū)類(lèi)型。支持基本的分區(qū)管理和查詢(xún)優(yōu)化。

?MySQL 5.5：對(duì)分區(qū)表的查詢(xún)優(yōu)化有所改進(jìn)，提升了性能。

?MySQL 5.6：引入了更多的分區(qū)管理功能，包括 subpartition 子分區(qū)、分區(qū)交換操作、CHECK 約束等。

?MySQL 5.7：進(jìn)一步增強(qiáng)了分區(qū)表的功能，包括 hash 分區(qū)類(lèi)型、NOWAIT 選項(xiàng)、ALTER TABLE ... EXCHANGE PARTITION 和 ALTER TABLE ... REBUILD PARTITION 等操作。

?MySQL 8.0：繼續(xù)對(duì)分區(qū)表進(jìn)行優(yōu)化和增強(qiáng)，包括對(duì)于自動(dòng)生成分區(qū)鍵值、分區(qū)表的查詢(xún)性能提升等方面的改進(jìn)。

這樣看起來(lái)，這不完全Cover住了分表的概念嗎？甚至，這不比業(yè)界的分表做的還要好嗎。

那為什么我們還要癡迷于分表，或許我們可以采用分區(qū)的邏輯吧？

當(dāng)然，還有一些延伸到運(yùn)維操作，舉個(gè)例子：

分區(qū)表怎么擴(kuò)容

詳見(jiàn) ALTER TABLE 語(yǔ)句

1.創(chuàng)建新分區(qū)：使用 ALTER TABLE 命令添加新的分區(qū)。例如，如果是按照時(shí)間范圍分區(qū)的表，可以增加新的時(shí)間范圍的分區(qū)。

ALTER TABLE your_partitioned_table
ADD PARTITION (PARTITION p_new VALUES LESS THAN (new_value));

這里的 new_value 是新的分區(qū)范圍。

2. 數(shù)據(jù)遷移：使用 ALTER TABLE ... REORGANIZE PARTITION 命令將現(xiàn)有分區(qū)中的數(shù)據(jù)遷移到新的分區(qū)中。例如，可以通過(guò)將舊分區(qū)的數(shù)據(jù)移動(dòng)到新分區(qū)來(lái)實(shí)現(xiàn)。

ALTER TABLE your_partitioned_table
REORGANIZE PARTITION old_partition INTO
(PARTITION p_new VALUES LESS THAN (new_value));

這里的 old_partition 是要移動(dòng)數(shù)據(jù)的舊分區(qū)。

3. 數(shù)據(jù)清理（可選）：在確認(rèn)數(shù)據(jù)遷移成功后，可以考慮清理不再需要的舊分區(qū)。使用 ALTER TABLE ... DROP PARTITION 命令可以刪除不再需要的舊分區(qū)。

ALTER TABLE your_partitioned_table
DROP PARTITION old_partition;

這里的 old_partition 是要?jiǎng)h除的舊分區(qū)。

顯而易見(jiàn)，這是一個(gè)原地?cái)U(kuò)容操作，我們或許不需要引入什么復(fù)雜的組建或者邏輯去做resharding。

落地方案猜測(cè)

我們或許可以在單表業(yè)務(wù)場(chǎng)景下遇到問(wèn)題瓶頸后采用分區(qū)的概念，如果分區(qū)不夠可以采用原地?cái)U(kuò)容邏輯。當(dāng)機(jī)器達(dá)到瓶頸后采用分庫(kù)的概念達(dá)成分庫(kù)分區(qū)的邏輯。

這只是一個(gè)猜想，對(duì)于我們的數(shù)據(jù)庫(kù)廠商，其實(shí)只需要將這套邏輯維護(hù)好做到高可用的邏輯即可。

當(dāng)然，圍繞著分區(qū)和物理數(shù)據(jù)庫(kù)我們還有很多擴(kuò)展內(nèi)容可以去做，但是這篇文章旨在說(shuō)明，或許我們不應(yīng)該被分庫(kù)分表約束了思維，或許我們不需要做分布式的邏輯，或許在機(jī)器性能良好的場(chǎng)景下我們單機(jī)器就可以cover住我們的數(shù)據(jù)量。

此外，一個(gè)數(shù)據(jù)庫(kù)產(chǎn)品或許應(yīng)該做到serverless的概念，我們用戶(hù)不需要理解這么多的邏輯，至于分區(qū)或許這個(gè)看MySQL文檔都可以學(xué)習(xí)到。

審核編輯 黃宇