做分庫分表這件事我是拖到實在沒辦法才動的。單庫單表數(shù)據(jù)量沖上千萬、億級之后慢SQL、鎖競爭、備份耗時、連接數(shù)打滿這些事會接踵而來。而ShardingSphere是目前把分庫分表落地得最順手的中間件之一這篇文章會圍繞一個訂單系統(tǒng)把從分片鍵選型、算法配置、項目代碼到生產(chǎn)問題排查的完整過程寫清楚都是我在實際項目里驗證過的方案和踩過的坑。如果你是數(shù)據(jù)量還沒到瓶頸、純想了解技術(shù)選型這套拆解同樣值得讀完畢竟分庫分表最怕的不是不會用而是用得時機不對、拆得方案不對后面想回頭都難。1. 為什么我的項目需要分庫分表一個真實的演進過程很多團隊一開始并不會主動想拆庫甚至覺得這是技術(shù)債。我在的訂單項目也一樣一年多時間訂單總量到了四千多萬單表查詢開始明顯變慢加上后臺要跑各種統(tǒng)計業(yè)務(wù)側(cè)又不斷加字段單庫單表的路基本到頭了。1.1 單庫單表撐不住的那一刻四千多萬的數(shù)據(jù)量單表即使建立了合理的索引B樹深度撐到三層、四層隨機查詢的代價其實還能接受。真正扛不住的問題出在幾個地方寫沖突和鎖競爭嚴重。下單高峰時段同一個熱點用戶、同一個商品維度的行鎖競爭業(yè)務(wù)接口的P99延遲一路飆升。備份和恢復(fù)時間越來越離譜。一張超過幾十GB的大表每次全量備份要按小時計算恢復(fù)演練基本沒法做。數(shù)據(jù)歸檔困難。想把一年前的數(shù)據(jù)挪到歷史表單庫單表做起來要么鎖表要么影響線上。索引和統(tǒng)計信息失效。大表頻繁更新后執(zhí)行計劃經(jīng)常出現(xiàn)不穩(wěn)定同樣的查詢時快時慢。這些信號湊齊之后分庫分表就是必需品而不是炫技。拆分的直接目標(biāo)有兩個一是把單表數(shù)據(jù)量控制下來保證索引和查詢穩(wěn)定二是把寫入壓力分散到多個庫減少單點鎖和連接壓力。1.2 垂直拆分與水平拆分的取舍拆分的思路大體分兩類垂直拆分和水平拆分。兩者并不是互斥關(guān)系實際生產(chǎn)中往往是先垂直后水平。垂直拆分是按業(yè)務(wù)域拆庫比如訂單庫、用戶庫、支付庫各管各的。垂直拆分的收益是模塊職責(zé)清晰服務(wù)之間互不干擾但局限也很明顯——它解決不了單表數(shù)據(jù)量持續(xù)膨脹的問題訂單表該有八千萬還是八千萬。水平拆分才是本文的核心。它的做法是把同一張表的數(shù)據(jù)按某種規(guī)則分散到多個庫、多張表里。以訂單表為例可以按用戶ID取模分成2個庫每個庫再分成4張表整體形成8張結(jié)構(gòu)完全一樣的表數(shù)據(jù)按分片鍵均勻散落。我建議你在動手前先把概念理清楚維度垂直拆分水平拆分拆分對象按業(yè)務(wù)域拆表/拆庫按數(shù)據(jù)行拆表/拆庫解決的問題業(yè)務(wù)耦合、單庫連接壓力單表數(shù)據(jù)量過大、寫入瓶頸實施難度相對簡單主要是應(yīng)用改造涉及路由、擴容、數(shù)據(jù)一致性典型場景微服務(wù)化、業(yè)務(wù)模塊解耦千萬級以上的訂單、消息、流水真實項目里我見過不少團隊一開始只做垂直拆分結(jié)果發(fā)現(xiàn)訂單庫還是太大于是又重新做水平拆分。所以方案設(shè)計階段建議把未來兩年的數(shù)據(jù)增量一并估算進去避免重復(fù)改造。1.3 為什么最終選了 ShardingSphere主流的中間件方案有ShardingSphere和MyCat兩類。ShardingSphere-JDBC以jar包方式運行在應(yīng)用側(cè)相當(dāng)于給應(yīng)用注入了一個增強的數(shù)據(jù)源ShardingSphere-Proxy則是獨立部署一個代理服務(wù)用MySQL協(xié)議對外提供連接。MyCat偏向Proxy模型但多年的社區(qū)迭代和生態(tài)活躍度其實不如ShardingSphere。我最終選ShardingSphere理由很直接和Spring Boot集成非常順滑配置文件寫好就能用對已有代碼的侵入性小。分片策略、分布式ID、讀寫分離、數(shù)據(jù)加密這些功能是完整的不用自己在外面拼湊。支持標(biāo)準JDBC接口MyBatis、Spring Data JPA都能無縫對接。5.x版本的內(nèi)核做了重寫SQL解析和改寫能力比4.x時代強不少。特別說明一下這篇文章的示例用的是ShardingSphere 5.x版本配置結(jié)構(gòu)和老版本差異很大如果你搜到的是4.x資料請對版本保持足夠的警覺。2. 分片前的準備工作確定維度與分片算法很多項目翻車不是中間件用錯了而是分片鍵選錯了。分片鍵決定了一條SQL會被路由到哪個庫、哪張表如果選得不好后面的查詢復(fù)雜度會成倍上升。2.1 分片鍵怎么選三個硬性條件我在訂單項目里選擇分片鍵時堅持三個條件業(yè)務(wù)高頻使用。分片鍵必須在絕大多數(shù)查詢語句中作為條件出現(xiàn)。用戶端查我的訂單條件必然帶user_id所以user_id就是第一分片鍵。數(shù)據(jù)分布足夠均勻。分片鍵的取值離散程度要高不能讓某個值的數(shù)據(jù)量占掉半邊天。例如按用戶ID取?；钴S用戶和沉默用戶的ID在哈?？臻g上分布比較均勻整體是可控的。無更新或極少更新。分片鍵一旦在業(yè)務(wù)中被更新就會面臨數(shù)據(jù)搬家、路由失效的問題。所以user_id這種穩(wěn)定字段比手機號、郵箱這類可變字段更適合。訂單表我采用了雙分片鍵的輔助設(shè)計主分片鍵是user_id用于定位到庫和表同時order_id作為分布式主鍵用于單條訂單查詢時的精準定位。這里有個關(guān)鍵經(jīng)驗如果你只按order_id路由而沒有user_id那這條SQL在不知道從哪個分片找數(shù)據(jù)的情況下只能全庫全表路由性能直接崩掉。所以在設(shè)計表結(jié)構(gòu)時一定把user_id冗余到所有訂單相關(guān)表中并且所有查詢盡量帶上它。2.2 分片算法怎么定取模、哈希還是時間分片ShardingSphere支持多種分片算法常用的有以下幾種INLINE取模。寫法類似t_order_$-{user_id % 4}理解成本最低適合數(shù)據(jù)量平穩(wěn)增長、分片數(shù)穩(wěn)定的場景。HASH_MOD。先將分片鍵做哈希再取模適合字符串類型的業(yè)務(wù)字段比如手機號、訂單編號。RANGE時間范圍。比如按月份拆表適合流水、日志、審計類數(shù)據(jù)。這種方案的好處是擴容簡單按時間加表就行缺點是可能產(chǎn)生熱點表。CLASS_BASED自定義算法。當(dāng)內(nèi)置算法解決不了業(yè)務(wù)規(guī)則時自己實現(xiàn)分片算法類。我的訂單場景用的是INLINE取模。計算公式如下庫路由user_id % 2結(jié)果0進ds01進ds1表路由user_id % 4結(jié)果0到3分別進t_order_0到t_order_3舉個例子user_id 10001時庫是10001 % 2 1表是10001 % 4 1數(shù)據(jù)落在ds1的t_order_1里。這個計算過程ShardingSphere會在SQL執(zhí)行前自動完成但你要自己能算得出來否則排查問題時兩眼一抹黑。2.3 分布式ID必須提前換掉自增主鍵分庫分表之后數(shù)據(jù)庫自增主鍵就整體失效了因為每個分片各自維護一套自增必然產(chǎn)生沖突。我的項目直接用ShardingSphere內(nèi)置的雪花算法SNOWFLAKE生成order_id。雪花算法生成的ID是一個64位的Long整型由時間戳、機器號、序列號組成趨勢遞增、全局唯一。在ShardingSphere里配置非常省事rules: sharding: key-generators: snowflake: type: SNOWFLAKE props: worker-id: 1表的配置里再指定主鍵生成策略key-generate-strategy: column: order_id key-generator-name: snowflake這樣插入時只需要設(shè)置業(yè)務(wù)字段order_id會自動生成并回填到實體對象中。有一點要注意雪花算法強依賴機器時鐘如果部署環(huán)境的NTP時鐘同步出問題可能會出現(xiàn)ID重復(fù)。生產(chǎn)環(huán)境務(wù)必做好時鐘校驗這也是我踩過一次的坑。3. 項目實戰(zhàn)訂單系統(tǒng)分庫分表完整配置前面是理論鋪墊從這節(jié)開始進入真正的項目實操。以下配置和應(yīng)用代碼都在訂單項目中驗證過你可以直接作為腳手架參考。3.1 版本選型與工程依賴項目基礎(chǔ)是Spring Boot 2.7JDK 8。ShardingSphere選擇5.3.2版本這個版本相對穩(wěn)定API和配置結(jié)構(gòu)清晰。引入依賴時注意一個坑ShardingSphere 5.x對應(yīng)的starter是shardingsphere-jdbc-core-spring-boot-starter不是老版本的sharding-jdbc-spring-boot-starter兩個名字別搞混。dependency groupIdorg.apache.shardingsphere/groupId artifactIdshardingsphere-jdbc-core-spring-boot-starter/artifactId version5.3.2/version /dependency持久層框架用的是MyBatis Plus。因為ShardingSphere對外暴露的是標(biāo)準DataSource接口所以MyBatis這套根本感知不到后端有多庫多表應(yīng)用代碼寫起來和單庫單表時幾乎一樣。3.2 數(shù)據(jù)源與分片規(guī)則配置詳解兩個物理庫分別叫order_db_0、order_db_1每個庫里預(yù)建4張訂單表t_order_0到t_order_3。表結(jié)構(gòu)完全一致DDL需要在每個庫里各執(zhí)行一遍。Spring Boot的application.yml配置如下spring: shardingsphere: datasource: names: ds0, ds1 ds0: type: com.zaxxer.hikari.HikariDataSource driver-class-name: com.mysql.cj.jdbc.Driver jdbc-url: jdbc:mysql://10.1.1.10:3306/order_db_0?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: xxx maximum-pool-size: 10 minimum-idle: 2 ds1: type: com.zaxxer.hikari.HikariDataSource driver-class-name: com.mysql.cj.jdbc.Driver jdbc-url: jdbc:mysql://10.1.1.11:3306/order_db_1?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: xxx maximum-pool-size: 10 minimum-idle: 2 rules: sharding: tables: t_order: actual-data-nodes: ds$-{0..1}.t_order_$-{0..3} database-strategy: standard: sharding-column: user_id sharding-algorithm-name: db_inline table-strategy: standard: sharding-column: user_id sharding-algorithm-name: table_inline key-generate-strategy: column: order_id key-generator-name: snowflake t_order_item: actual-data-nodes: ds$-{0..1}.t_order_item_$-{0..3} database-strategy: standard: sharding-column: user_id sharding-algorithm-name: db_inline table-strategy: standard: sharding-column: user_id sharding-algorithm-name: item_table_inline binding-tables: - t_order, t_order_item sharding-algorithms: db_inline: type: INLINE props: algorithm-expression: ds$-{user_id % 2} table_inline: type: INLINE props: algorithm-expression: t_order_$-{user_id % 4} item_table_inline: type: INLINE props: algorithm-expression: t_order_item_$-{user_id % 4} props: sql-show: true一點一點拆解關(guān)鍵部分actual-data-nodes定義了表實際分布在哪些數(shù)據(jù)源和物理表中$-{0..1}、$-{0..3}是ShardingSphere的內(nèi)置枚舉表達式表示區(qū)間展開。database-strategy和table-strategy分別負責(zé)分庫和分表路由。algorithm-expression里的表達式是Groovy語法user_id % 2直接對參數(shù)值計算。sql-show: true會在日志里輸出改寫后的真實SQL開發(fā)排查時非常有用生產(chǎn)環(huán)境建議關(guān)閉。3.3 綁定表與廣播表的正確姿勢訂單表往往還要關(guān)聯(lián)訂單明細表。如果兩張表都分片連接查詢時如果沒有約束會產(chǎn)生笛卡爾積路由也就是每一個庫表組合都會執(zhí)行一次join性能災(zāi)難。解決方案是配置綁定表讓t_order和t_order_item使用相同的分片鍵和相同的分片算法。這樣關(guān)聯(lián)查詢時比如t_order o JOIN t_order_item i ON o.order_id i.order_idShardingSphere會根據(jù)o表的路由結(jié)果直接把i表定位到同一個分片避免無效連接。廣播表則相反它代表全庫復(fù)制的小表比如訂單狀態(tài)字典、配送方式字典。這類表在每個分片庫都放一份完整數(shù)據(jù)查詢時直接在當(dāng)前庫讀取不會跨庫。rules: sharding: broadcast-tables: - t_dict注意廣播表適合低頻更新、數(shù)據(jù)量小的字典類數(shù)據(jù)千萬別把大表配成廣播表否則每個庫都存一份巨大的冗余維護成本極高。3.4 核心業(yè)務(wù)代碼插入與查詢的全鏈路數(shù)據(jù)源和規(guī)則配置好之后業(yè)務(wù)代碼的寫法和平時幾乎一致。插入訂單加明細整個鏈路的核心在ShardingSphere的路由改寫過程。我用的Mapper示例Mapper public interface OrderMapper { Insert(INSERT INTO t_order(order_id, user_id, order_amount, status, create_time) VALUES (#{orderId}, #{userId}, #{orderAmount}, #{status}, #{createTime})) int insert(OrderEntity order); Select(SELECT * FROM t_order WHERE user_id #{userId} AND order_id #{orderId}) OrderEntity selectByIdAndUserId(Param(userId) Long userId, Param(orderId) Long orderId); }插入時如果沒有顯式給order_id賦值ShardingSphere的key-generator會自動生成并回填。比如userId10001時ShardingSphere內(nèi)部先計算路由user_id % 2 1目標(biāo)庫ds1user_id % 4 1目標(biāo)表t_order_1日志里的sql-show會打印類似這樣的改寫結(jié)果INSERT INTO ds1.t_order_1(order_id, user_id, order_amount, status, create_time) VALUES (987654321, 10001, 1999, 1, 2024-06-01 12:00:00)查詢訂單詳情時SQL里同時帶上了user_id和order_id路由就能精確定位效率很高。這里提醒一句千萬別在Mapper里寫不帶user_id的單條件查詢比如WHERE order_id #{orderId}。這條SQL雖然能在單表時代正確工作在分庫分表后必然觸發(fā)全庫全表路由誰能堅持誰后悔。4. 分頁、排序與跨分片查詢怎么辦分庫分表后最麻煩的往往不是簡單查詢而是跨分片的分頁排序。這類問題不做限制后臺管理頁面可能直接把數(shù)據(jù)庫拖垮。4.1 業(yè)務(wù)場景分層用戶端與后臺端的分野我把業(yè)務(wù)查詢拆成了兩類分別設(shè)計不同策略一種是用戶端查詢條件里一定帶user_id比如“我的訂單列表”。這種查詢天然被分片鍵約束只需要路由到特定分片再在本地分頁排序性能可控。另一種是后臺管理端查詢條件可能是下單時間、訂單狀態(tài)、商品名稱就是不帶user_id。這種查詢必須路由到全部分片再把結(jié)果匯總排序風(fēng)險最大。用戶端接口沒什么好講的按正常寫法就行。后臺端才是真正的技術(shù)難點我在項目里給后臺列表單獨設(shè)計了一套方案而不是讓運營同學(xué)直接查業(yè)務(wù)庫。4.2 跨分片分頁的原理與優(yōu)化思路當(dāng)一條SQL無法根據(jù)分片鍵裁剪路由范圍時ShardingSphere會把SQL改寫后發(fā)送到所有分片執(zhí)行然后對各個分片的結(jié)果集做歸并。比如SELECT * FROM t_order WHERE create_time BETWEEN 2024-05-01 AND 2024-05-31 ORDER BY order_amount DESC LIMIT 10, 10這條SQL會路由到全部8張分表每張表各自查10條最后ShardingSphere在內(nèi)存中匯總排序截取第10到20條。這里有個搜索引擎和數(shù)據(jù)庫都會遇到的經(jīng)典問題如果偏移量很大比如LIMIT 100000, 20每個分片都要把前100020條撈出來再歸并內(nèi)存和時間開銷都非常嚇人。我實踐下來的優(yōu)化手段有三條限制深度分頁。后臺列表最多翻到第100頁超過就要求運營人員加篩選條件從產(chǎn)品層面消掉深度分頁需求這是性價比最高的手段。游標(biāo)分頁代替偏移分頁。用上一頁的最后一條訂單金額和創(chuàng)建時間作為下一頁的查詢條件讓查詢每次都只取固定窗口不隨頁碼加深而變慢。引入?yún)R總索引存儲。把后臺所需的查詢字段同步到Elasticsearch或者ClickHouse讓后臺列表查索引存儲不碰業(yè)務(wù)分片庫。這實際上也是我最后真正落地的方案。如果你不想引入新組件還能在數(shù)據(jù)庫層采取月份分表的策略把時間范圍條件也作為分片依據(jù)從而把后臺查詢裁剪到少數(shù)幾個分片。4.3 讀寫分離在分庫場景中的落地分庫處理寫壓力讀壓力的問題則需要讀寫分離來解決。ShardingSphere支持在分片規(guī)則之下配置每個分片的讀庫。我當(dāng)時的配置思路是每個物理主庫外掛一主一從主庫負責(zé)寫從庫分擔(dān)讀。配置結(jié)構(gòu)如下spring: shardingsphere: datasource: names: ds0_write, ds0_read, ds1_write, ds1_read rules: readwrite-splitting: >HintManager hintManager HintManager.getInstance(); hintManager.setWriteRouteOnly(); try { orderMapper.selectByOrderId(orderId); } finally { hintManager.close(); }主從延遲是這個方案里最大的變量延遲超過業(yè)務(wù)容忍閾值時建議監(jiān)控主從延遲時間并觸發(fā)降級把讀流量全部切到主庫。5. 生產(chǎn)環(huán)境常見問題與排查實錄分庫分表的報錯往往千奇百怪但歸因之后大多是幾個固定套路。我把項目上線以來遇到的高頻問題整理成一份速查表再展開講幾個典型的翻車現(xiàn)場。5.1 高頻異常及解決速查表現(xiàn)象原因解決方法找不到分片目標(biāo)表actual-data-nodes表達式寫錯核對邏輯表名與實際表名檢查$-{0..3}區(qū)間SQL提示無法路由SQL里沒有分片鍵改造SQL帶上分片鍵或使用Hint強制路由join查詢結(jié)果重復(fù)綁定表未配置在binding-tables中聲明關(guān)聯(lián)表插入數(shù)據(jù)報主鍵沖突應(yīng)用配置了自增或者worker-id沖突改由ShardingSphere生成雪花ID并檢查各節(jié)點worker-id唯一查詢莫名全庫路由表達式里的列名和庫表列名不一致檢查sharding-column和SQL條件里的列名完全一致連接數(shù)耗盡實例過多或連接池配置過大控制maximum-pool-size按分片數(shù)估算總連接數(shù)這幾類問題里最常見、最隱蔽的是分片列名不匹配。比如sharding-column配置成了大寫列名SQL里寫的是小寫ShardingSphere識別不了直接把SQL當(dāng)成無分片鍵處理。5.2 分片不生效的典型翻車現(xiàn)場有次線上后臺查詢訂單列表SQL里明明帶了user_id執(zhí)行計劃卻還是全庫全表路由。我查了半天最后發(fā)現(xiàn)表里根本沒有user_id這一列查詢條件里寫的是order表的別名而ShardingSphere是根據(jù)邏輯列名去匹配分片鍵的列名對不上就退化為全路由。還有一個翻車案例是綁定表沒配全。訂單表和訂單明細表明明配置了綁定表但某個報表SQL又加了第三張分片表做join結(jié)果只有前兩張表被綁定路由第三張表全部路由一遍查詢耗時從幾十毫秒變成幾十秒。排查方式很簡單把sql-show打開看改寫SQL凡是出現(xiàn)多組不同分片的SQL就說明綁定關(guān)系沒生效。建議所有分片表的分片鍵列都統(tǒng)一命名為相同名稱比如都用user_id這樣配置最省心連接查詢也最容易匹配。不要出現(xiàn)這張表用user_id、那張表用buyer_id的分歧那是給自己埋雷。5.3 連接數(shù)與慢SQL的性能監(jiān)控分庫分表乍一看每個庫連接數(shù)不大但應(yīng)用實例一多很容易把數(shù)據(jù)庫連接數(shù)打滿。我算過一個公式總連接數(shù)等于應(yīng)用實例數(shù)乘以每實例連接池大小再乘以分片庫數(shù)。如果20個實例、每實例連接池最大20、2個分片庫就是800個數(shù)據(jù)庫連接。如果數(shù)據(jù)庫配置的max_connections是1000留下系統(tǒng)和其他服務(wù)余量后已經(jīng)非常危險。所以我建議每實例連接池的maximum-pool-size不要拍腦袋亂配5到10是常態(tài)最大不超過20。連接池不是越大越好大連接池只會放大單實例故障時的雪崩效應(yīng)。慢SQL監(jiān)控這件事在分庫分表環(huán)境里比單庫時代更重要。同一個慢SQL會并發(fā)打到多個分片影響會被放大數(shù)倍。我不僅收集應(yīng)用側(cè)的執(zhí)行耗時還會在數(shù)據(jù)庫端開啟慢查詢?nèi)罩救缓蟀催壿嫳砻S度聚合分析。一旦某張分片表出現(xiàn)熱點數(shù)據(jù)索引優(yōu)化必須馬上跟進。6. 擴容與數(shù)據(jù)遷移提前規(guī)劃好出路分庫分表一旦做了擴容就是躲不掉的話題。很多人以為拆完就萬事大吉結(jié)果數(shù)據(jù)量翻倍后才發(fā)現(xiàn)之前定的2庫4表不夠用了這才意識到擴容比初次拆分還要痛苦。6.1 從2庫4表擴到4庫8表會遇到什么以我的訂單表為例初始設(shè)計是user_id % 2分庫、user_id % 4分表。當(dāng)單表數(shù)據(jù)量再次逼近閾值時我面臨兩個選項保持邏輯分片規(guī)則不變只擴大每個物理庫的容量例如換更大的磁盤、更強的CPU。調(diào)整分片算法比如改為user_id % 4分庫、user_id % 8分表讓數(shù)據(jù)更分散。第二種方案聽上去更“徹底”但代價非常大。因為取?；鶖?shù)的變化幾乎所有存量數(shù)據(jù)都要重新計算目標(biāo)分片然后搬運。以前user_id 10001在ds1的t_order_1改成% 4和% 8之后它可能被路由到ds3的t_order_7實際遷移比例接近七成。這就是為什么分片鍵的取?；鶖?shù)要提前規(guī)劃的原因之一。如果你預(yù)估未來數(shù)據(jù)量可能翻四倍那初始就一步到位拆成4庫8表而不是2庫4表。分片數(shù)量太少會提前觸發(fā)擴容分片數(shù)量太多又浪費資源和運維成本這個平衡點要靠數(shù)據(jù)增長模型來推算。6.2 停機遷移與在線遷移的選擇擴容時的數(shù)據(jù)遷移行業(yè)里常見方案無非兩種停機遷移和在線遷移。停機能接受的情況下我推薦最樸素的做法提前寫好導(dǎo)出工具把所有分片數(shù)據(jù)導(dǎo)出成文件再按新路由規(guī)則計算目標(biāo)分片逐個導(dǎo)入新庫然后做總量核對和抽樣校驗。在線遷移則要復(fù)雜得多大體思路是應(yīng)用層同步雙寫新老兩套分片同時寫入。用數(shù)據(jù)同步工具把歷史數(shù)據(jù)從老分片遷移到新分片。校驗完成后將應(yīng)用讀流量灰度切到新分片觀察一段時間。確認穩(wěn)定后關(guān)掉老分片寫入完成割接。這種方案對雙寫一致性的要求極高事務(wù)邊界稍微處理不當(dāng)就會出現(xiàn)數(shù)據(jù)漏寫或重復(fù)。所以我的實踐建議是如果業(yè)務(wù)允許停機維護盡量停機遷移把復(fù)雜度降到最低如果一定要在線遷移優(yōu)先考慮引入Canal這類binlog訂閱同步工具而不是手動在業(yè)務(wù)代碼里雙寫。擴容和數(shù)據(jù)遷移這件事沒有一勞永逸的銀彈。真正可靠的辦法是在設(shè)計階段就留足余量在運維階段提前演練遷移流程把最壞情況下的回滾方案也一并驗證好。我在實際項目里反復(fù)確認過一件事分庫分表絕對不是把配置寫上、數(shù)據(jù)拆開就結(jié)束了。它牽涉到緩存設(shè)計、查詢路由、分布式事務(wù)、數(shù)據(jù)遷移、監(jiān)控告警等一系列配套改造。如果你正準備上手建議從最簡單的2庫分表起步先把鏈路跑通再逐步擴展。中間件是工具業(yè)務(wù)量才是決定方案的那把尺子。