概述

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

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

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

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

接下來從頭縷一下數(shù)據(jù)庫選型的問題吧（以下均以MySQL的Innodb場景為例）：

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

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

這導(dǎo)致：

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

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

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

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

等等。。

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

分表

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

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

分庫

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

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

分區(qū)

相關(guān)文檔

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

分區(qū)表的實(shí)現(xiàn)原理其實(shí)和分表差不太多，不過它更靠近文件系統(tǒng)，而沒有經(jīng)過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ū)類型。支持基本的分區(qū)管理和查詢優(yōu)化。

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

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

?MySQL 5.7：進(jìn)一步增強(qiáng)了分區(qū)表的功能，包括 hash 分區(qū)類型、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ū)表的查詢性能提升等方面的改進(jìn)。

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

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

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

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

詳見 ALTER TABLE 語句

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ū)中。例如，可以通過將舊分區(qū)的數(shù)據(jù)移動(dòng)到新分區(qū)來實(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ū)。

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

落地方案猜測(cè)

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

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

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

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