概述
這篇文章沒什麼太多的乾貨，純純是一篇討論和思考帖。
從業數據庫領域三年有餘了，從分庫分表中間件到數據庫團隊內核學到了很多東西。也接觸了很多項目，包括TiDB、Vitess、Polardb、StarDB等等。
國內的項目好像很多都聚焦於分庫分表的概念，包括很多的數據庫團隊都在嘗試這個概念的落地和沉溺於性能的跑分。
最近我在預覽MySQL官方，看到了Partitioning的概念，而且佔據了很大的篇幅。不由得引人思考，爲什麼這個概念在我接觸的業務中沒有被廣泛的使用呢？或許我們將來可以有分庫分區的概念？
接下來從頭縷一下數據庫選型的問題吧（以下均以MySQL的Innodb場景爲例）：
分表、分區、分庫有什麼用處
在那個遠古的時代，物理機器的配置很低，當數據量增大的時候，傳統的B+樹的高度會越來越高，我們對硬件資源的要求很高，機器往往內存爆倉、IO打滿等等。
這導致：
查詢速度顯著下降。複雜的查詢、索引失效、全表掃描等操作變得緩慢。
在大表中創建和維護索引可能會消耗大量的時間和資源。插入、更新和刪除操作可能需要花費更長的時間來維護索引，導致性能下降。
讀寫操作可能導致鎖衝突，降低系統的併發處理能力，甚至引發死鎖問題。
備份、恢復、數據清理、空間管理等操作變得困難，維護成本和風險增加。
等等。。
後來我們引出了第一個概念：分表
分表
在 5.1版本以前，MySQL並沒有分區的概念，爲了解決這個問題，無非是單表拆成雙表、多表之類的，這樣將一個表要面臨的問題分散成了兩個表或者多個表共同承受。
反思當下，在當前這個物理資源冗餘的時代，大部分業務場景下我們的單表真的會比分表的性能差很多嗎？有多少時候我們是爲了分表而分表？我們的分表邏輯或許需要我們支持更多的功能，比如彈性、事務、一些查詢語句的改寫，然後一遍一遍的造輪子給運維帶來無盡的痛苦。
分庫
分表的解決能力還是有限的，我們一臺物理機器的能力也是有限的，這時候或許我們可以採用分表的形式，來避免熱點問題或者單機器壓力過載的問題。
將一個庫要面臨的問題分散成了兩個庫或者多個庫共同承受。
分區
在5.1版本以後MySQL出了一個國內幾乎無人問津的分區表的功能。
分區表的實現原理其實和分表差不太多，不過它更靠近文件系統，而沒有經過MySQL的應用層或者引擎層。MySQL的物理數據，存儲在表空間文件（.ibdata1和.ibd）中，這裏講的分區的意思是指將同一表中不同行的記錄分配到不同的物理文件中，幾個分區就有幾個.idb文件。
隨着 MySQL 版本的更新迭代，分區功能也在後續版本中不斷得到改進和增強。具體的分區功能支持情況如下：
•MySQL 5.1：引入了 Range 和 List 兩種分區類型。支持基本的分區管理和查詢優化。
•MySQL 5.5：對分區表的查詢優化有所改進，提升了性能。
•MySQL 5.6：引入了更多的分區管理功能，包括 subpartition 子分區、分區交換操作、CHECK 約束等。
•MySQL 5.7：進一步增強了分區表的功能，包括 hash 分區類型、NOWAIT 選項、ALTER TABLE ... EXCHANGE PARTITION 和 ALTER TABLE ... REBUILD PARTITION 等操作。
•MySQL 8.0：繼續對分區表進行優化和增強，包括對於自動生成分區鍵值、分區表的查詢性能提升等方面的改進。
這樣看起來，這不完全Cover住了分表的概念嗎？甚至，這不比業界的分表做的還要好嗎。
那爲什麼我們還要癡迷於分表，或許我們可以採用分區的邏輯吧？
當然，還有一些延伸到運維操作，舉個例子：
分區表怎麼擴容
1.創建新分區：使用 ALTER TABLE 命令添加新的分區。例如，如果是按照時間範圍分區的表，可以增加新的時間範圍的分區。
ALTER TABLE your_partitioned_table
ADD PARTITION (PARTITION p_new VALUES LESS THAN (new_value));
這裏的 new_value 是新的分區範圍。
2. 數據遷移：使用 ALTER TABLE ... REORGANIZE PARTITION 命令將現有分區中的數據遷移到新的分區中。例如，可以通過將舊分區的數據移動到新分區來實現。
ALTER TABLE your_partitioned_table
REORGANIZE PARTITION old_partition INTO
(PARTITION p_new VALUES LESS THAN (new_value));
這裏的 old_partition 是要移動數據的舊分區。
3. 數據清理（可選）：在確認數據遷移成功後，可以考慮清理不再需要的舊分區。使用 ALTER TABLE ... DROP PARTITION 命令可以刪除不再需要的舊分區。
ALTER TABLE your_partitioned_table
DROP PARTITION old_partition;
這裏的 old_partition 是要刪除的舊分區。
顯而易見，這是一個原地擴容操作，我們或許不需要引入什麼複雜的組建或者邏輯去做resharding。
落地方案猜測
我們或許可以在單表業務場景下遇到問題瓶頸後採用分區的概念，如果分區不夠可以採用原地擴容邏輯。當機器達到瓶頸後採用分庫的概念達成分庫分區的邏輯。
這只是一個猜想，對於我們的數據庫廠商，其實只需要將這套邏輯維護好做到高可用的邏輯即可。
當然，圍繞着分區和物理數據庫我們還有很多擴展內容可以去做，但是這篇文章旨在說明，或許我們不應該被分庫分表約束了思維，或許我們不需要做分佈式的邏輯，或許在機器性能良好的場景下我們單機器就可以cover住我們的數據量。
此外，一個數據庫產品或許應該做到serverless的概念，我們用戶不需要理解這麼多的邏輯，至於分區或許這個看MySQL文檔都可以學習到。