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