作者：張俊杰

概述

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

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

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

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

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

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

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

這導致：

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

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

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

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

等等。。

后來我們引出了第一個概念：分表

分表

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

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

分庫

分表的解決能力還是有限的，我們一臺物理機器的能力也是有限的，這時候或許我們可以采用分表的形式，來避免熱點問題或者單機器壓力過載的問題。

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

分區(qū)

?相關(guān)文檔

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

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

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

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

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

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

?MySQL 5.7：進一步增強了分區(qū)表的功能，包括 hash 分區(qū)類型、NOWAIT 選項、ALTER TABLE ... EXCHANGE PARTITION 和 ALTER TABLE ... REBUILD PARTITION 等操作。

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

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

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

當然，還有一些延伸到運維操作，舉個例子：

分區(qū)表怎么擴容

詳見 ALTER TABLE 語句

1.創(chuàng)建新分區(qū)：使用 ALTER TABLE 命令添加新的分區(qū)。例如，如果是按照時間范圍分區(qū)的表，可以增加新的時間范圍的分區(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ù)移動到新分區(qū)來實現(xiàn)。

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

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

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

ALTER TABLE your_partitioned_table
DROP PARTITION old_partition;

這里的 old_partition 是要刪除的舊分區(qū)。

顯而易見，這是一個原地擴容操作，我們或許不需要引入什么復雜的組建或者邏輯去做resharding。

落地方案猜測

我們或許可以在單表業(yè)務場景下遇到問題瓶頸后采用分區(qū)的概念，如果分區(qū)不夠可以采用原地擴容邏輯。當機器達到瓶頸后采用分庫的概念達成分庫分區(qū)的邏輯。

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

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

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

審核編輯 黃宇