1.引言

“你做過分庫分表嗎？”

這是我在社招面試中，被問到次數(shù)最多的一句話之一。

一聽到這個問題，我心里就會一緊：又來了，這道送命題。

有次面試官剛說完這句，我就順勢來了一句：“您是想聽垂直分表還是水平分表？”

面試官笑了笑說：“那就從水平分表講講吧。”

于是，我的故事就這么開始了。

2.緣起：那張幾乎讓系統(tǒng)崩潰的訂單表

幾年前，我接手一個電商系統(tǒng)。

訂單表 order_info 有將近 5000萬行數(shù)據(jù)，每次查詢都慢得要命。特別是那種根據(jù)用戶ID查最近10條訂單的接口，在高并發(fā)的促銷活動中，簡直是災難級的存在。

日志刷得像彈幕，CPU飆升到90%，DBA一臉無奈地說：“小米，再不分表，這臺數(shù)據(jù)庫就要冒煙了。”

那一刻，我意識到：是時候出大招了——水平分表。

3.什么是水平分表？

簡單來說，水平分表就是：

當一張表數(shù)據(jù)太多時，我們不去拆字段，而是“橫著切”。

比如原來有一張大表：order_info

我們可以根據(jù)某個維度（比如用戶ID、訂單ID、時間），拆成多張：

圖片

每張表的結(jié)構(gòu)完全相同，只是數(shù)據(jù)不同。

就像把一個超大的文件夾，拆成多個小文件夾，每個文件夾里只放部分文件，這樣查起來快得多。

4.水平分表的幾種常見策略

做分表，最關(guān)鍵的問題是：怎么分？

這一步?jīng)Q定了你后續(xù)是“順風順水”，還是“痛不欲生”。我在項目中踩過不少坑，總結(jié)下來有三種主流方案：

1）按范圍（Range）分表

比如：

• 2023年數(shù)據(jù)放 order_info_2023
• 2024年數(shù)據(jù)放 order_info_2024

優(yōu)點：

• 查詢某一時間段的數(shù)據(jù)非常快。
• 數(shù)據(jù)歸檔方便。

缺點：

• 熱點數(shù)據(jù)集中在最新表，容易出現(xiàn)單表壓力。
• 需要定期建新表，否則新的一年沒表可寫。

2） 按哈希（Hash）分表

比如用 user_id % 16 決定分到哪個表：

圖片

優(yōu)點：

• 數(shù)據(jù)分布相對均勻。
• 并發(fā)高時能顯著提升性能。

缺點：

• 不方便做跨分片統(tǒng)計。
• 分表數(shù)量固定，后期擴容比較麻煩。

3） 按業(yè)務(wù)維度（如地區(qū)、商戶等）分表

例如：

• 華北區(qū)：order_info_north
• 華南區(qū)：order_info_south

優(yōu)點：

• 邏輯清晰，方便獨立維護。

缺點：

• 不同區(qū)域用戶分布不均時，容易出現(xiàn)“冷熱表”。

5.水平分表的難點：不止是“拆表”那么簡單

很多人以為水平分表就只是建幾張表，分幾條數(shù)據(jù)。其實，真上生產(chǎn)你會發(fā)現(xiàn)，最麻煩的是后續(xù)問題：

1）跨表查詢

比如：

老板想查“近一年所有訂單總額”，可你訂單分散在16張表里——咋辦？

解決辦法：

• 寫程序邏輯循環(huán)查詢再合并結(jié)果；
• 或者用中間件（如 ShardingSphere、MyCat）來幫你分片聚合。

2） 自增主鍵不再唯一

原來用 AUTO_INCREMENT 一路走天下，結(jié)果分成16張表后，各自自增，沖突了。

解決辦法：

• 用 雪花算法（Snowflake）、UUID、自定義發(fā)號器；
• 或者用分布式ID服務(wù)（如 Leaf、TinyID）。

3）事務(wù)問題

跨表、跨庫后，事務(wù)就不再是單機的事了。這時候要用 分布式事務(wù) 或 最終一致性 模式。如果不控制好，可能出現(xiàn)“扣錢成功但沒下單”的烏龍。

4）數(shù)據(jù)遷移與擴容

最痛苦的環(huán)節(jié)來了——擴容。當你的16張表都快爆滿時，想擴到32張？

不好意思，哈希算法全得改，數(shù)據(jù)要重分布，遷移代價巨大。所以，分表前一定要預留足夠的分片空間！

6.那什么時候該用水平分表？

這是面試中很容易被反問的點。我一般這么回答：

“當單表數(shù)據(jù)量超過千萬級、單表查詢頻繁且明顯影響性能時，就可以考慮水平分表。”

具體來說，判斷標準可以參考以下幾個信號：

圖片

7.水平分表的最佳實踐：從入門到進階

下面是我個人總結(jié)的一套“分表成長路徑”：

1）起步階段：代碼手動分表

• 最常見，也最靈活。通過代碼控制表名。
• 適合中小型項目，但后期維護成本高。

2）進階階段：引入中間件

比如：

• Apache ShardingSphere
• MyCat
• Oceanus

中間件能自動路由SQL、合并結(jié)果、管理分片策略。這時開發(fā)只管寫SQL，不用關(guān)心底層有多少表。

3）成熟階段：配合分庫分表、讀寫分離

分表只是開始。真正的架構(gòu)優(yōu)化，還包括：

• 分庫：不同業(yè)務(wù)拆不同數(shù)據(jù)庫；
• 讀寫分離：主庫寫，從庫讀；
• 緩存：用Redis做熱點數(shù)據(jù)加速。

當你把這些配合起來，就能撐住雙十一的洪峰流量了。

8.面試官最喜歡問的那幾個“陷阱問題”

如果你正在準備面試，一定要注意以下幾個點：

問題1：水平分表后怎么做分頁查詢？

用全局排序字段（如創(chuàng)建時間或雪花ID），然后程序聚合分頁。

問題2：分表后如何保證唯一約束？

通過全局ID生成器或唯一索引服務(wù)統(tǒng)一管理。

問題3：分表后數(shù)據(jù)統(tǒng)計怎么辦？

通過異步統(tǒng)計、定時任務(wù)、或數(shù)據(jù)倉庫做匯總。

面試官問這些不是為了難你，而是想看你是否真的考慮過線上問題。

9.結(jié)語：分表不是萬能藥，合理才是關(guān)鍵

說實話，水平分表這件事，就像減肥。開始的時候很爽，性能嗖嗖提升；但后期維護、遷移、擴容的時候，你會哭著回憶從前的簡單生活。

所以我常跟團隊說：“能不分就不分，能靠索引優(yōu)化、緩存解決的，就別輕易動分表。”

有時候，一個合適的索引、一層緩存、或一個中間件配置，都比你動刀分表來得劃算。

寫到這兒，我回想起當年第一次上線分表方案那晚，凌晨兩點，測試環(huán)境跑通后，我們幾個人端著咖啡舉杯慶祝。

那一刻我突然明白：所謂“架構(gòu)師的浪漫”，大概就是能讓系統(tǒng)穩(wěn)定地跑下去吧。

總結(jié)一句話：水平分表，是一把雙刃劍。它能讓性能飛升，也可能讓你后悔。想用好它，先搞懂業(yè)務(wù)，再規(guī)劃架構(gòu)。