幾年前我接手過一個訂單系統(tǒng)單表數(shù)據(jù)量破了億高峰期一個簡單的 count 查詢就要跑好幾秒慢日志把監(jiān)控面板刷得通紅。那時候擺在團隊面前的方案就是今天要聊的分庫分表。分完之后單表壓力確實下來了但隨之而來的問題也一個接一個冒出來全局ID、跨庫Join、分布式事務(wù)、深分頁還有最頭疼的擴容遷移。這篇文章我會按自己在生產(chǎn)環(huán)境里的踩坑順序把分庫分表后暴露出來的典型問題逐個拆開講清楚底層原因和可行的解決方案。適合正在準備分庫分表的團隊、被分片問題折磨的后端開發(fā)以及想系統(tǒng)理清這套架構(gòu)思路的人。有一些方案屬于行業(yè)通用做法我會額外標注哪些是來自我的實踐經(jīng)驗供你參考。1. 分庫分表前必須想清楚的那筆賬1.1 它到底解決了什么問題先別急著追求“用了分庫分表就高級”。分庫分表本質(zhì)上解決的是三個現(xiàn)實瓶頸。第一是連接數(shù)問題。MySQL 這類數(shù)據(jù)庫的連接是有限資源一個實例的連接數(shù)一旦被占滿新請求只能在連接池里排隊等。很多系統(tǒng)的數(shù)據(jù)量不大但應(yīng)用實例多、連接池配得又大單庫連接數(shù)很容易被打爆。分庫之后連接壓力被分散到多個實例上這個問題會立刻緩解。第二是單表數(shù)據(jù)量膨脹后索引性能下降。這里有個容易誤解的地方B樹索引本身能支撐千萬級數(shù)據(jù)3到4層深度其實還挺能打。但真實生產(chǎn)環(huán)境不是教科書大量歷史數(shù)據(jù)堆積、頁碎片增加、隨機回表變多幾億行的單表會讓很多簡單查詢變得很慢尤其帶 order by、group by 的時候慢查詢幾乎躲不掉。分表把數(shù)據(jù)拆成多份每張物理表的數(shù)據(jù)量降下來索引效率自然恢復(fù)。第三是單庫的寫入吞吐天花板。一個主庫的磁盤IO、binlog寫入、刷盤能力都有上限。日增百萬行以上的業(yè)務(wù)單庫寫入很容易成為瓶頸。分庫分表后寫入被分散到多個節(jié)點這個天花板就被抬高了。我經(jīng)手的那個訂單系統(tǒng)就是這樣單表日均新增幾十萬行大促期間一個簡單寫操作排隊幾百毫秒庫的連接數(shù)和CPU都頂不住。分完立刻立竿見影但也只是“開始”。1.2 分完之后你失去了什么可以這么理解分庫分表前你的數(shù)據(jù)庫是一個大倉庫你想怎么盤點都行分完之后倉庫被切成幾十個小隔間找特定商品很快但跨隔間盤點就得挨個進去數(shù)再在外面匯總。這是分庫分表最核心的代價用犧牲“全局視圖”換“伸縮能力”。具體來說你至少會失去以下東西跨庫 Join 能力原本一條 SQL 關(guān)聯(lián)三張表分庫后如果數(shù)據(jù)不在同一個庫這條 SQL 基本廢了。本地事務(wù)邊界原本一個事務(wù)里同時更新訂單、庫存、余額分庫后它們可能在不同庫ACID 不再由單庫保證。唯一索引約束user_name 這類全局唯一字段在分片后的數(shù)據(jù)庫里無法靠單表唯一索引兜底。全局排序、分頁、聚合count、sum、avg 這些操作都要先分散查詢再歸并深分頁更是災(zāi)難。DDL 與索引管理原來對一張表加個索引現(xiàn)在要對幾十張表操作窗口期成倍拉長。所以分庫分表是一個“確定性有損方案”。它不是優(yōu)化技巧是為了可用性和容量做出的取舍。動手之前最該做的事情就是把現(xiàn)有 SQL 全部梳理一遍按“能帶路由鍵的查詢”“不帶路由鍵的查詢”“跨分片查詢”分類。很多團隊跳過這一步拆分之后才發(fā)現(xiàn)核心列表頁全是跨分片查詢等于把單表的慢查詢換成了更復(fù)雜的跨分片慢查詢。1.3 分庫還是分表垂直還是水平不少人把“分庫分表”當(dāng)成一個詞其實它們是不同的手段解決的問題也不一樣。分庫是把不同業(yè)務(wù)域的數(shù)據(jù)放到不同數(shù)據(jù)庫實例比如把訂單庫、用戶庫、支付庫拆開。它主要解決單庫連接、IO、CPU 瓶頸。很多時候一個實例扛不住只是因為所有業(yè)務(wù)擠在一起垂直分庫就夠了根本不用水平分表。分表是把一張大表按行拆成多張結(jié)構(gòu)相同的物理表。它主要解決單表數(shù)據(jù)量過大、索引效率下降的問題。比如訂單表按 user_id 哈希拆成 64 張每張表只存原來的 1/64 數(shù)據(jù)。垂直拆分是按列拆把熱點字段和冷字段分開減少單行數(shù)據(jù)體積提高緩存命中率。水平拆分才是通常說的“分表”也是這里要討論的重點。判斷標準我一般這樣簡化單庫連接或 CPU 扛不住優(yōu)先分庫單表數(shù)據(jù)量過大、索引性能明顯退化優(yōu)先分表一張表字段特別多且冷熱訪問差異極大考慮垂直拆分。拆鍵的選擇則是最關(guān)鍵的決定。理想路由鍵要覆蓋 80% 以上的查詢。比如訂單高頻查詢是“查某個用戶的訂單列表”那就按 user_id 拆如果是“按訂單號查訂單詳情”那就按 order_id 拆。注意這兩個鍵往往只能二選一選了 user_id所有按 order_id 的查詢就會退化成全分片掃描。如果你兩種查詢都很高頻就得考慮冗余表或者異構(gòu)存儲來兜住另一種查詢方式。2. 分布式主鍵、跨庫Join與唯一約束第一個痛感來源2.1 全局唯一ID自增主鍵的替代方案分庫分表后單表自增主鍵立刻失效。原因很簡單兩個分片各自從 1 開始自增會出現(xiàn)重復(fù) ID。你說我可以設(shè)置不同的初始值和步長比如庫1生成 1,3,5庫2生成 2,4,6這確實能撐一陣子但后期擴容要重新調(diào)整步長歷史數(shù)據(jù)還得重新計算維護成本很高不推薦。實際生產(chǎn)里常用的方案有三類我做過對比方案特點適用場景業(yè)務(wù)規(guī)則ID用日期用戶ID序列拼出訂單號天然唯一且可讀訂單號、流水號等業(yè)務(wù)強相關(guān)場景號段模式集中發(fā)號服務(wù)每次取一批號本地內(nèi)存分配需要高性能、實現(xiàn)簡單的場景雪花算法時間戳機器標識序列號趨勢遞增分布式節(jié)點多、需要本地生成ID的場景UUID全局唯一但隨機無序不適合做數(shù)據(jù)庫主鍵只適合做鏈路追蹤等UUID 不建議當(dāng)主鍵這是我在實際中踩過的坑。UUID 沒有順序性作為聚簇索引主鍵時新數(shù)據(jù)會隨機插入索引頁導(dǎo)致頁分裂頻繁寫入性能和磁盤碎片都很難看。雪花算法是當(dāng)前最主流的方案核心結(jié)構(gòu)是 1 位符號位 41 位毫秒時間戳 10 位機器標識 12 位序列號。它能保證全局唯一并且趨勢遞增對索引比較友好。但有一個經(jīng)典問題時鐘回撥。如果機器 NTP 校時后時間往回跳就可能生成重復(fù) ID。我實踐中的做法是記錄上一次生成 ID 的時間戳如果當(dāng)前時間小于等于上次時間就拒絕生成或者阻塞等待時鐘恢復(fù)同時配合機器標識位做兜底。號段模式也很值得提一下它的思路是集中發(fā)號服務(wù)在數(shù)據(jù)庫里維護一個“當(dāng)前最大號段”每次申請取一批號比如一次取 1000 個應(yīng)用本地分配。這樣發(fā)號服務(wù)壓力小性能高實現(xiàn)也簡單。缺點是發(fā)號服務(wù)仍然是個單點需要做好高可用取號窗口也不能太小否則會造成頻繁訪問發(fā)號庫。我自己在中等規(guī)模系統(tǒng)里很喜歡用號段模式因為維護成本遠低于雪花算法。2.2 跨庫Join習(xí)慣了SQL的人最先懵掉的地方分庫之后一條 SQL 關(guān)聯(lián)多張表還能不能跑取決于你的拆鍵設(shè)計。最理想的情況是經(jīng)常一起 Join 的父子表使用同一個路由鍵。比如訂單表和訂單明細表都按 order_id 分片那么同一筆訂單的數(shù)據(jù)天然落在同一個分片單庫 Join 依然可用。這一點應(yīng)該在設(shè)計拆鍵時優(yōu)先考慮能幫你省掉大量后續(xù)麻煩。但現(xiàn)實往往是用戶表和訂單表沒法用同一個鍵拆。訂單按 user_id 分片用戶表又按 user_id 分片這其實還能對得上。就怕訂單按 order_id、用戶按 user_id兩套路由體系那么“查詢訂單并顯示買家昵稱”就必然跨分片?？绶制?Join 的常規(guī)解法有四種冗余字段。把查詢列表需要的買家昵稱、商品標題等字段直接冗余到訂單表寫入時多寫一份查詢時無需關(guān)聯(lián)。這是最簡單也最有效的方案絕大多數(shù)訂單列表展示場景都夠用。應(yīng)用層組裝。先在分片里查出訂單數(shù)據(jù)再根據(jù) user_id 集合批量調(diào)用用戶服務(wù)查詢昵稱最后在服務(wù)內(nèi)存里拼裝。要注意控制批量查詢的 IN 條件長度分片查詢也盡量并發(fā)。寬表/匯總表。把高頻查詢需要的維度都同步到一張寬表里這張表可以單獨存儲查詢走它。本質(zhì)上是建立一個面向查詢的模型。異構(gòu)存儲。復(fù)雜關(guān)聯(lián)和檢索直接交給搜索引擎或者分析型存儲業(yè)務(wù)庫只承擔(dān)在線交易寫入。我的建議是優(yōu)先冗余字段其次應(yīng)用層組裝別在業(yè)務(wù)代碼里硬撐復(fù)雜 Join。分庫分表之后SQL 不再是萬能膠水這條認知越早建立越好。2.3 唯一約束失效唯一索引在分片下不靈了分庫分表后一個容易被忽略的問題是唯一約束失效。比如用戶表的用戶名需要全局唯一但表按 user_id 分片之后每個分片只能檢查自己分片內(nèi)有沒有重名無法判斷其他分片的同名情況。數(shù)據(jù)庫層的唯一索引在這里形同虛設(shè)。解決思路有三條。第一條讓業(yè)務(wù)規(guī)則保證唯一。比如訂單號本身由全局發(fā)號器生成規(guī)則上就不會重復(fù)這時數(shù)據(jù)庫層不需要唯一索引兜底。適合有明確業(yè)務(wù)編號的場景。第二條建立“唯一鍵 → 路由鍵”的映射表。以用戶名注冊為例先在一張獨立的全局映射表里插入用戶名和 user_id 的對應(yīng)關(guān)系映射表本身可以做唯一索引插入成功后再把用戶數(shù)據(jù)寫入 user_id 對應(yīng)的分片。并發(fā)重復(fù)注冊時映射表的唯一索引會把沖突擋在外面。代價是多一次查詢和一次額外寫入。第三條路由鍵本身如果是唯一字段比如 user_id 本身全局唯一那就不存在額外約束問題直接用路由鍵作為唯一條件即可。這套機制需要額外引入一張映射表增加一次網(wǎng)絡(luò)交互很多人會覺得麻煩。但這是分庫分表的固有復(fù)雜度躲是躲不掉的。不做映射表的話就得自己做分布式鎖而且要處理鎖粒度、鎖超時、鎖釋放復(fù)雜度只會更高。3. 跨庫分頁、排序與聚合業(yè)務(wù)代碼里最隱蔽的坑3.1 深分頁為什么是災(zāi)難分頁這個功能看起來人畜無害但分庫分表之后它是隱藏極深的性能殺手。先看單庫分頁select * from order where user_id 100 order by create_time desc limit 100000, 20。MySQL 會掃描前 100020 行丟棄前 100000 行再返回 20 行。單庫這個操作已經(jīng)很重了但還能咬牙撐住。分庫之后就完全不同了。假設(shè)拆了 16 個分片你要取全局第 100000 到 100020 條不能只查詢每個分片的后 20 條因為全局排完序之后第 100000 條可能分布在任何分片里。正確做法是每個分片各取前 100020 條然后合并排序再截取第 100001 到 100020 條。每個分片都得傳輸十萬級數(shù)據(jù)到聚合層內(nèi)存和 CPU 開銷呈線性放大offset 越大代價越高。這還不算最慘的。如果分頁查詢沒帶路由鍵比如管理員后臺按狀態(tài)查訂單所有分片都得參與那就是 16 倍的掃描量。解決方案我實踐下來最有效的是這三種禁止深分頁。前端頁碼限制到 100 頁以內(nèi)超出就提示用戶縮小查詢范圍。很多業(yè)務(wù)場景其實根本不需要翻到很深。鍵集分頁也叫 keyset pagination / 游標分頁。不依賴 offset而是記住上一頁最后一條數(shù)據(jù)的排序字段值。例如 order by create_time desc, id desc下一頁就查詢 where create_time ? or (create_time ? and id ?) order by create_time desc, id desc limit 20。這樣每頁查詢都能利用索引數(shù)據(jù)量再大也能保持穩(wěn)定的查詢耗時?？绶制判蚍猪摻唤o搜索引擎。業(yè)務(wù)庫只負責(zé)寫入搜索引擎負責(zé)維護倒排索引列表頁和后臺查詢?nèi)孔咚阉鞣?wù)。這是大型系統(tǒng)里最穩(wěn)妥的路線。方案優(yōu)點缺點傳統(tǒng) offset 分頁實現(xiàn)簡單前端友好深分頁性能災(zāi)難跨分片必放大游標/鍵集分頁性能穩(wěn)定適合列表不能跳頁需要知道上一頁錨點搜索引擎分頁支持復(fù)雜條件排序引入額外組件有數(shù)據(jù)同步延遲3.2 全局排序、count與avg的歸并陷阱排序和分頁是連在一起的?？绶制判虻幕舅悸肥敲總€分片先按排序字段排序取出前 N 條聚合層做歸并排序再取出最終結(jié)果。但如果排序字段不是路由鍵這個“每個分片取前 N 條”并不等于全局前 N 條需要每個分片取的量足夠大最后結(jié)果才準確。所以跨分片排序的復(fù)雜度不僅來自排序本身還來自“取多少才夠”的不確定性。生產(chǎn)上最簡單的做法就是限制查詢范圍或者直接把排序場景遷移到搜索引擎。再說 count 和 avg這兩個函數(shù)都有考核點。count(*) 在單庫是一條索引掃描分庫后就必須“各分片 count 再累加”。如果業(yè)務(wù)量每小時都要做一次精確全量計數(shù)對分片的壓力很大。更合理的做法是維護一張匯總表或者直接由分析引擎提供計數(shù)能力。avg 有一個非常經(jīng)典的坑不能直接把各分片的 avg 加起來再求平均。正確的計算方式是 avg sum(所有分片的總和) / count(所有分片的總數(shù))。因為各分片的數(shù)據(jù)量可能不均勻簡單平均結(jié)果會偏。這個我在代碼評審里見過不止一次看起來是小問題一旦數(shù)據(jù)分布傾斜報表數(shù)據(jù)直接失真。sum 也一樣需要先各分片 sum再匯總。min、max 反而簡單各分片取自身最大最小再取極端值即可。3.3 分組統(tǒng)計在分片下的正確姿勢group by 的問題比單值聚合更隱蔽。比如要統(tǒng)計“每個城市的訂單量”但訂單表是按 user_id 分片的同一個城市的用戶分散在各個分片每個分片只能算出自己的城市分組要得到全局分組必須把所有分片的小組結(jié)果合并然后按城市維度重新聚合。如果數(shù)據(jù)量不大這種歸并還能接受。但一旦分片多、基數(shù)大應(yīng)用層需要做一次完整的 MapReduce非常難受。在線上交易庫里做分組統(tǒng)計我強烈建議三條路只允許按路由鍵分組。例如按 user_id 分片就只做 user 維度的分組這樣每個分片獨立算結(jié)果直接匯總即可。把分組鍵作為二級分片鍵建設(shè)維度表或匯總表。異步預(yù)聚合。寫入時同步到分析型數(shù)據(jù)庫或搜索引擎報表和統(tǒng)計全部從這邊出。這是大型系統(tǒng)的通行做法也是我實際最喜歡的方案。分庫分表永遠是為在線事務(wù)服務(wù)的不是為了數(shù)據(jù)分析更好。分析類的復(fù)雜聚合應(yīng)該盡早導(dǎo)出到專用引擎而不是在業(yè)務(wù)庫上硬扛。4. 分布式事務(wù)從本地ACID到最終一致性的思維切換4.1 單庫事務(wù)為什么不能直接搬到分庫分庫之前一個下單操作通常是這樣開啟事務(wù)插入訂單表扣減庫存表更新賬戶余額然后提交。如果中間任何一步失敗本地事務(wù)回滾數(shù)據(jù)保持一致。分庫分表之后訂單、庫存、余額很可能在不同的庫甚至不同的物理機。你無法再用一個數(shù)據(jù)庫事務(wù)把它們包起來——每個庫的事務(wù)是獨立的Commit 的時候可能訂單庫提交成功、庫存庫提交失敗系統(tǒng)立即處于不一致狀態(tài)。這就是分布式事務(wù)要解決的問題。很多人一開始試圖找一種“像本地事務(wù)一樣”的分布式事務(wù)框架但分布式環(huán)境下沒有免費的午餐你必須接受一個事實跨庫操作的原子性要么依賴協(xié)調(diào)協(xié)議要么靠最終一致性補償。一個非常實用的建議在拆鍵設(shè)計階段盡量把強一致相關(guān)的數(shù)據(jù)放到同一個分片。比如“訂單和訂單明細”本來就在同一個庫里關(guān)聯(lián)那就保持同一路由鍵“用戶余額變動”和“訂單創(chuàng)建”如果無法避免跨分片則需要認真評估業(yè)務(wù)上是否真的需要強一致。4.2 幾種主流的分布式事務(wù)方案怎么選我把實際工程里見得最多的方案拉個表給你參考方案一致性強度開發(fā)成本適用場景XA 兩階段提交強一致低一致性要求極高、并發(fā)量不大TCC 補償最終一致高跨服務(wù)資金操作需自定義補償本地消息表/事務(wù)消息最終一致中訂單、異步通知最通用SAGA 長事務(wù)最終一致中高流程長、有明確正向/補償步驟XA 是數(shù)據(jù)庫原生支持的強一致方案邏輯簡單但兩階段提交的鎖持有時間長并發(fā)能力差在高頻寫入場景下基本扛不住。用在低并發(fā)、強一致的管理類操作還可以。TCC 需要業(yè)務(wù)方自己實現(xiàn) Try、Confirm、Cancel 三個動作。Try 階段預(yù)留資源Confirm 提交Cancel 回滾。這套方案靈活、性能比 XA 好但代碼量很大還要處理協(xié)調(diào)者的狀態(tài)和超時。我見過不少團隊用 TCC 處理支付扣款最后維護補償邏輯的成本非常高。本地消息表和事務(wù)消息是最終一致方案里性價比最高的。核心思路是在業(yè)務(wù)本地事務(wù)里同時寫入業(yè)務(wù)數(shù)據(jù)和一條待發(fā)送消息事務(wù)提交后再把消息發(fā)出去消費者異步處理后續(xù)步驟。由于業(yè)務(wù)數(shù)據(jù)和消息同庫提交不會出現(xiàn)“業(yè)務(wù)做了但消息沒發(fā)”的問題。很多消息中間件的事務(wù)消息做得更徹底把本地表都省了原理是一樣的。SAGA 把長事務(wù)拆成多個本地事務(wù)每一步有正向操作和補償操作。和 TCC 的區(qū)別是SAGA 沒有預(yù)留資源這一說直接執(zhí)行失敗時逆序補償。適合訂單流程長、步驟邊界清晰的場景。我的個人傾向是能用單庫事務(wù)解決就不做分布式事務(wù)必須跨庫時優(yōu)先事務(wù)消息和最終一致不要一上來就上 TCC 或 XA。真正的高并發(fā)系統(tǒng)核心訴求是“最終把事辦成且不重復(fù)”而不是“每一步都強一致”。4.3 兜底補償與對賬生產(chǎn)環(huán)境真正的保命手段再好的分布式事務(wù)方案在真實網(wǎng)絡(luò)環(huán)境下也會出現(xiàn)消息丟失、重復(fù)消費、超時無響應(yīng)。所以生產(chǎn)環(huán)境里真正靠得住的是兜底機制。第一是對賬。定期掃描所有跨庫業(yè)務(wù)的狀態(tài)數(shù)據(jù)找出不一致的記錄并觸發(fā)補償。比如訂單表和支付流水表對不上對賬任務(wù)自動補單或者告警人工介入。這是最終一致性的守護神比任何事務(wù)框架都重要。第二是冪等。下游消費方必須能冪等處理否則一條消息重復(fù)投遞就會造成重復(fù)扣款、重復(fù)發(fā)貨。冪等鍵一般用業(yè)務(wù)主鍵加事件類型處理前先查詢是否已處理。我分享一個真實教訓(xùn)有段時間我們上線了本地消息表機制以為萬事大吉結(jié)果忘了給消息表配置定期清理任務(wù)消息表膨脹到幾千萬行查詢越來越慢消費端延遲飆升。后來加上“消息表狀態(tài)掃描 定時補償”才穩(wěn)定下來。分布式事務(wù)只能降低不一致概率不能消滅不一致運維側(cè)的兜底永遠不能省。5. 擴容與數(shù)據(jù)遷移分庫分表真正的第二次考驗5.1 取模擴容的代價與一致性哈希很多人以為分庫分表是一勞永逸等容量不夠了才發(fā)現(xiàn)擴容才是最難的一步。最早期的方法是按 user_id % 16 取模拆成 16 個分片。這種方案在數(shù)據(jù)量增長到臨界點后想擴到 32 個分片問題就來了因為取模的模數(shù)變了原來大部分數(shù)據(jù)的路由結(jié)果都會變幾乎所有的數(shù)據(jù)都得重新搬遷。擴容不再是“加幾臺機器”的事而是一次接近全量遷移的大工程。一致性哈希是這里面的經(jīng)典解法。把哈希值空間組織成環(huán)機器落在環(huán)上數(shù)據(jù)按順時針歸屬到最近的節(jié)點。擴容時只需要把一部分數(shù)據(jù)從相鄰節(jié)點遷移到新節(jié)點遷移量比取模小得多。但一致性哈希也有自己的問題節(jié)點分布不均會導(dǎo)致數(shù)據(jù)傾斜需要引入虛擬節(jié)點來緩解同時遷移期間新舊映射要保證一致性否則會出現(xiàn)讀寫走不同節(jié)點的情況。另外按范圍分片比如按時間范圍、按ID區(qū)間在擴容時更靈活只需要切分某個區(qū)間的數(shù)據(jù)但缺點也很明顯最新數(shù)據(jù)往往集中在某個區(qū)段容易形成熱點。如果業(yè)務(wù)本來就是冷熱交替比如訂單按月份歸檔范圍分片反而很合適。所以沒有哪種分片算法是完美的只有適不適合當(dāng)前業(yè)務(wù)。5.2 邏輯分片與預(yù)分片平滑擴容的工程化思路這里介紹一個我在實踐中認為最值得推廣的方案邏輯分片與預(yù)分片。核心思想是把“分片編號”和“物理存儲位置”解耦。預(yù)先定義一批固定數(shù)量的邏輯分片比如 1024 個槽位每個槽位是一個邏輯概念它當(dāng)前映射到哪張物理表、哪個物理庫由一個路由表維護。寫入數(shù)據(jù)時先用路由鍵算出槽位編號再查路由表找到實際物理存儲位置。擴容時不需要改變槽位數(shù)量和路由算法只需要把一部分槽位從舊節(jié)點遷移到新節(jié)點并更新路由表即可。遷移粒度從“全量數(shù)據(jù)”變成“局部槽位”范圍可控影響面小。預(yù)分片的槽位數(shù)在設(shè)計時就要預(yù)留未來好幾年的增長空間比如先定 1024 個槽位映射到 16 個物理庫每庫 64 個槽位。將來擴到 32 個庫每庫分到的槽位變成 32 個數(shù)據(jù)只搬移那些槽位對應(yīng)的數(shù)據(jù)其他槽位紋絲不動。工程實現(xiàn)上路由表可以放到配置中心或本地進程緩存。這里有個小細節(jié)路由表變更期間要保證一致性最好引入版本號所有請求在同一個版本下解析路由等遷移完成再切換版本。否則遷移中途出現(xiàn)路由不一致數(shù)據(jù)就會讀到一半新一半舊的。預(yù)分片的實現(xiàn)比直接取模多一層映射初期確實有點多余但它是長期最省心的方案。如果團隊有中長期擴容預(yù)期建議一步到位。5.3 數(shù)據(jù)遷移的完整節(jié)奏從雙寫到灰度切換不管用哪種方案數(shù)據(jù)遷移都不是“停服拷貝”而是線上平滑切換。我自己跑過多次遷移基本固定成下面五步節(jié)奏。第一步建表與雙寫。在目標庫建好新表結(jié)構(gòu)業(yè)務(wù)寫入時同時寫舊表和按新規(guī)則映射的新表雙寫邏輯要能容忍重復(fù)數(shù)據(jù)最好以冪等寫入方式保證兩側(cè)一致。第二步全量遷移。用一致性快照或者離線任務(wù)把存量數(shù)據(jù)導(dǎo)入目標庫。如果數(shù)據(jù)量很大按槽位或按ID區(qū)間分批處理。第三步增量追平。通過數(shù)據(jù)庫的變更日志訂閱或者消息回放把雙寫期間產(chǎn)生的增量數(shù)據(jù)持續(xù)同步到目標庫直到目標庫和舊庫的數(shù)據(jù)延遲降到秒級以內(nèi)。第四步數(shù)據(jù)校驗。抽樣或者全量對比主鍵、版本號、排序字段。不一致的記錄要重新回放。這一步不要省我見過直接跳過校驗上線結(jié)果漏了部分分片的數(shù)據(jù)用戶反饋問題層出不窮。第五步灰度切換。先把少量讀寫流量切到新路由觀察指標逐步放大比例1% → 10% → 50% → 100%。每次放大后至少觀察一個業(yè)務(wù)周期確認無異常再繼續(xù)。窗口選擇低峰期出錯時還能快速回切。雙寫與增量同步期間還有一個常見坑新舊路由并存會導(dǎo)致部分數(shù)據(jù)重復(fù)。這個只能靠全鏈路冪等去兜比如每次寫入帶業(yè)務(wù)主鍵目標庫按主鍵去重?？傊w移本身不可怕可怕的是遷移方案里沒有回退預(yù)案和校驗機制。6. 反向經(jīng)驗有些表根本不該分庫分表6.1 什么情況下分庫分表是負優(yōu)化聊了這么多問題與解法我得潑一盆冷水很大一部分系統(tǒng)其實根本不需要分庫分表。一個典型場景是單表只有幾百萬行數(shù)據(jù)查詢幾十毫秒僅僅因為聽說“大廠都這么干”或者為了面試好聊就引入了分庫分表。結(jié)果每個查詢都要帶路由鍵不帶就全分片掃描跨分片查詢還引入額外的組裝邏輯性能比單庫更差。這種屬于典型的負優(yōu)化。另一個反例是業(yè)務(wù) SQL 本身特別復(fù)雜、關(guān)聯(lián)五六個表、查詢維度又多又雜的表。這種表一旦水平拆分幾乎所有查詢都會退化成跨分片掃描加上 MapReduce 式的歸并復(fù)雜度直接爆炸。對于這種表分庫分表只會讓系統(tǒng)更慢、更不穩(wěn)定。一個簡單判斷是如果分庫分表之后你的核心查詢依然需要頻繁跨分片且跨分片率超過 30%那大概率是拆錯了。正確做法是在拆分前就把查詢模式摸清而不是拆完再補。6.2 更輕的替代方案緩存、冷熱分離與異構(gòu)存儲很多以為需要分庫分表的問題其實用更輕的方案就能解決。讀多寫少、查詢熱點集中優(yōu)先上緩存。把高頻查詢結(jié)果緩存起來數(shù)據(jù)庫壓力立刻降下來。緩存都搞不定的高頻復(fù)雜查詢再考慮別的。歷史數(shù)據(jù)不參與在線查詢做冷熱分離或歸檔。以訂單系統(tǒng)為例三個月前的訂單查詢頻率驟降可以直接遷移到歸檔庫或大數(shù)據(jù)存儲在線庫只保留熱數(shù)據(jù)。這種方案比無腦水平分表更簡單效果也更直接。單庫連接和IO扛不住優(yōu)先垂直分庫。把用戶、訂單、商品放到不同實例互不影響。很多時候沒有水平拆分的必要只是多個業(yè)務(wù)域擠在一起了。復(fù)雜檢索、報表聚合這類需求最好直接交給搜索引擎或者分析型數(shù)據(jù)庫。讓在線事務(wù)庫承擔(dān)極少的高權(quán)重查詢其他分析類需求全部導(dǎo)出到專用引擎。這套組合拳下來真正需要水平分表的場景會少很多。6.3 我的選型判斷標準最后分享一套我自己的選型判斷框架純經(jīng)驗之談不一定絕對但值得參考單表數(shù)據(jù)量是否接近 5000 萬行以上并且持續(xù)增長單庫寫入 QPS 是否持續(xù)打到上千甚至更高連接數(shù)和 CPU 是否長期高水位核心業(yè)務(wù)是否已經(jīng)無法靠索引優(yōu)化、緩存、歸檔、讀寫分離來緩解最頻繁的查詢是否能以某一個固定鍵作為路由鍵收斂跨分片查詢比例是否足夠低團隊是否有人能長期維護路由、雙寫、對賬、遷移這套體系如果這五條里有兩條以上不滿足我都建議先不要分。因為分庫分表是用復(fù)雜度換容量收益必須明顯大于復(fù)雜度才有意義。我以前接手過一個“號稱已分庫分表”的老系統(tǒng)不少表才幾百萬行卻因為路由鍵設(shè)計不合理每個查詢都在全分片掃描比單庫還慢最后又把那些表合并回去了。這個內(nèi)容后續(xù)還可以這樣擴展把路由表、雙寫同步、對賬任務(wù)做成可觀測的治理平臺或者進一步思考冷熱混合存儲讓分片策略隨著數(shù)據(jù)生命周期動態(tài)調(diào)整。不過這些都是后話了先把上面這些問題想清楚分庫分表這條路才算真的走穩(wěn)了。