第一次接觸ShardingProxy的人通常是被一句話吸引過來的它能把你拆散在多個數(shù)據(jù)庫節(jié)點上的表重新拼成一個邏輯上的“普通數(shù)據(jù)庫”業(yè)務方不用改一行SQL就能繼續(xù)按單庫的習慣去讀寫。做數(shù)據(jù)庫中間件這行久了會發(fā)現(xiàn)很多團隊從單庫單表演進到分庫分表后卡住的往往不是拆分規(guī)則本身而是“怎么讓一百多個應用實例無縫切換到新架構(gòu)”。ShardingProxy正好是解決這個接入問題的關鍵一環(huán)。這篇文章我從頭講透它的原理、配置、實戰(zhàn)部署和排坑經(jīng)驗全部基于真實環(huán)境踩過的坑總結(jié)出來適合正在做分庫分表架構(gòu)選型的開發(fā)、DBA以及被拆分后的查詢路由搞得頭疼的同學參考。1. 先搞清楚ShardingProxy到底解決了什么問題1.1 從單庫單表到分庫分表問題從哪來先聊一個最常見的演進路徑。系統(tǒng)剛開始上線時一張訂單表就夠用后來業(yè)務量漲了單表千萬級、上億級索引深了寫并發(fā)高了數(shù)據(jù)庫的CPU和IO開始報警。于是DBA把訂單表按時間或者按訂單號拆成多張表再往后單庫也扛不住干脆把不同的表散到多個數(shù)據(jù)庫實例上。這個動作做完存儲壓力確實緩解了但應用端的麻煩才剛剛開始原來一條INSERT語句現(xiàn)在要自己算該去哪張表原來一個JOIN要跨多個庫手工拼數(shù)據(jù)原來一個事務現(xiàn)在要面對跨庫事務的難題。如果這些邏輯全部寫死在業(yè)務代碼里那每接入一個需求都要重新改一遍SQL拼接邏輯而且不同服務的分片規(guī)則不一致之后團隊維護成本會迅速失控。市面上解決這個問題的方式無非三種第一種是在應用層封裝數(shù)據(jù)訪問層把分片路由做在代碼里第二種是引入數(shù)據(jù)庫中間件讓SQL先經(jīng)過中間件再路由到后端節(jié)點第三種是把整個數(shù)據(jù)庫直接換成一個原生分布式數(shù)據(jù)庫。ShardingProxy屬于第二種也是我這些年見過在兼容性、改造成本和穩(wěn)定性之間平衡得比較好的方案。1.2 ShardingProxy與ShardingSphere生態(tài)的關系很多人會把ShardingSphere和ShardingProxy搞混。簡單說ShardingSphere是一套完整的數(shù)據(jù)庫生態(tài)下面兩條核心產(chǎn)品線一條是ShardingJDBC做成輕量級Java客戶端以jar包形式嵌入應用另一條就是ShardingProxy做成獨立部署的中間件服務對客戶端而言它就是一個標準數(shù)據(jù)庫服務端。兩者的定位差異很直觀。ShardingJDBC像是給每個應用請了一位貼身管家它跟著應用進程走路由規(guī)則直接內(nèi)置在JVM里性能損耗低但每個應用都要引入對應的依賴、配置分片規(guī)則。ShardingProxy則像是樓下的前臺總機你只管把SQL交給它它負責轉(zhuǎn)給背后各個數(shù)據(jù)庫節(jié)點業(yè)務側(cè)完全感知不到分庫分表的存在。這種差異決定了它們的適用場景完全不同。新寫一個微服務明確規(guī)定從零開始我傾向于ShardingJDBC因為侵入可控、鏈路短但如果要接的是存量系統(tǒng)幾十個服務每個都改JDBC連接方式成本太高或者對接的是異構(gòu)語言比如PHP、Python、Go沒辦法直接復用Java端的ShardingJDBC那ShardingProxy幾乎是唯一現(xiàn)實的選擇。我實際遇到過幾個項目數(shù)據(jù)庫表都拆好了但業(yè)務團隊有Java有Go還有寫存儲過程的最后統(tǒng)一收口到ShardingProxy所有客戶端只改一個連接地址問題立刻變簡單。1.3 為什么選Proxy而不是JDBC模式每次做技術選型團隊里都會有人問既然ShardingJDBC性能更好為什么還要引入一個單獨的中間層這個問題我一般從三個維度來回答。從運維視角看ShardingJDBC的分片規(guī)則散落在每個應用進程里規(guī)則要調(diào)整時必須發(fā)版重啟幾十上百個實例同時變更是個災難ShardingProxy把規(guī)則集中在服務端DBA改配置文件后重啟單點即可控制力強得多。從團隊協(xié)作看分片規(guī)則本質(zhì)上是一種“數(shù)據(jù)基礎設施約定”放在Proxy層由DBA或基礎架構(gòu)組統(tǒng)一維護比指望每個業(yè)務開發(fā)都理解取模算法要可靠。從生態(tài)兼容看Proxy透明地實現(xiàn)了MySQL和PostgreSQL網(wǎng)絡協(xié)議意味著任何能用這兩種協(xié)議連接數(shù)據(jù)庫的客戶端工具、監(jiān)控系統(tǒng)、BI軟件都能直接復用。當然Proxy也有代價。多一跳網(wǎng)絡就意味著額外的幾毫秒延遲加上中間件的CPU和內(nèi)存開銷對延遲極端敏感的純交易場景需要壓測確認。我的真實感受是如果你做的是內(nèi)部系統(tǒng)、報表平臺、ToB應用或者是存量系統(tǒng)改造Proxy的優(yōu)勢遠大于這點性能損耗如果每個接口對單次查詢延遲都有硬性要求且團隊全是Java且愿意接受強侵入改造再認真考慮ShardingJDBC。沒有銀彈適合的才是對的。2. 部署前的關鍵概念邏輯庫、物理庫、綁定表與分片算法2.1 邏輯庫、邏輯表與物理節(jié)點剛接觸ShardingProxy時最容易糊涂的就是配置里那一堆“邏輯”和“物理”的概念。我用最簡單的話解釋邏輯庫是客戶端看到的庫邏輯表是客戶端看到的表物理庫和物理表才是真正存在數(shù)據(jù)庫里的東西。比如你在Proxy里定義一個邏輯庫叫sharding_db客戶端執(zhí)行USE sharding_db然后查詢SELECT * FROM t_order WHERE order_id 1001。Proxy拿到這條SQL后先根據(jù)order_id的分片算法算出這條數(shù)據(jù)在物理表t_order_1上再根據(jù)庫分片規(guī)則算出它在物理庫ds0上于是真實執(zhí)行的是SELECT * FROM ds0.t_order_1 WHERE order_id 1001。整個過程對客戶端完全透明。這個“邏輯和物理分離”的設計價值在于它解耦了業(yè)務代碼和存儲拓撲。今天訂單表拆成4張明天拆成8張只需要改Proxy的配置業(yè)務SQL里的表名永遠叫t_order。我在項目里經(jīng)常開玩笑說分片規(guī)則是DBA和中間件之間的秘密業(yè)務開發(fā)不該也不需要知道。配置里的actualDataNodes就是用來告訴Proxy“這實這些物理表散落在哪里”的字段格式是ds0.t_order_0, ds0.t_order_1...也可以用行表達式簡寫成ds$-{0..1}.t_order_$-{0..3}。2.2 分片策略標準、復合與行表達式的實際使用分片策略是整個配置的重頭戲它決定了SQL會被路由到哪幾張物理表。常見的類型有三種標準分片、復合分片和HINT分片。標準分片是使用最多的場景它針對一個分片鍵做路由比如order_id對4取模或者按月份分表。配置時通過shardingColumn指定分片鍵在shardingAlgorithms里定義算法類型INLINE是最常用的行表達式算法比如t_order_$-{order_id % 4}表達的就是按訂單號對4取模落到4張表中。復合分片適合需要用兩個字段一起決定路由的場景比如先按用戶ID分庫再按訂單時間分表這時候需要實現(xiàn)一個自定義的復合算法類。HINT分片則是在SQL里完全不帶分片鍵時強制指定走哪個節(jié)點適合一些特殊的管理查詢。選算法時我的建議是能用取模就用取模模數(shù)按未來兩年數(shù)據(jù)增長預估再留出一倍余量。按時間分片適合歸檔類數(shù)據(jù)比如按月分表然后定期把歷史表遷移到冷存儲按用戶維度分片適合C端應用因為絕大部分查詢都是圍繞某個用戶展開的。記住一個要點分片鍵的選擇本質(zhì)上是和業(yè)務查詢模式強綁定的不是DBA隨便拍腦袋定的最忌諱的就是選了一個業(yè)務上根本不作為查詢條件的字段結(jié)果每條SQL都變成全路由廣播。2.3 綁定表與廣播表被低估的兩個配置分庫分表后跨節(jié)點JOIN是最讓人頭疼的問題。比如t_order和t_order_item都按order_id分片如果分片規(guī)則完全一致那么應該把兩個表配置成綁定表。綁定表的意思是兩個表在路由時會強制使用相同的分片路由結(jié)果t_order查了ds0.t_order_1t_order_item也只會去ds0.t_order_item_1查JOIN變成了單庫內(nèi)的普通JOIN不需要中間件做內(nèi)存聚合。廣播表則適合那些數(shù)據(jù)量很小、幾乎每個分片節(jié)點都需要用到的表比如字典表、配置表、省份城市表。這類表在每個物理庫里都存一份全量數(shù)據(jù)Proxy在寫入時會自動廣播到所有節(jié)點查詢時任選一個節(jié)點即可。配置方式是在rules里用!BROADCAST聲明兩張表之后應用完全感知不到它的存在。這兩個配置看起來不起眼但在實際并發(fā)場景里作用極大。我看到過太多團隊沒配綁定表結(jié)果一次本來很簡單的聯(lián)表查詢被拆成幾十次子查詢中間件內(nèi)存被打爆然后懷疑Proxy性能不行的案例。歸根結(jié)底中間件不是萬能加速器它只是在SQL路由上幫你做了正確的事數(shù)據(jù)分布設計不合理再好的中間件也救不回來。3. 實戰(zhàn)部署從下載到跑通第一條分片查詢3.1 環(huán)境準備與安裝包選擇說再多原理不如親手跑一次。這里我用一個模擬訂單場景來做實戰(zhàn)演示兩個物理庫ds0和ds1每個庫里有4張訂單表t_order_0到t_order_3通過Proxy對外暴露成一個邏輯庫sharding_db。操作系統(tǒng)準備一臺Linux我這邊測試用的是CentOS 7其他主流發(fā)行版沒區(qū)別提前裝好JDK 8。因為ShardingProxy本身是JVM進程所有數(shù)據(jù)庫驅(qū)動已經(jīng)內(nèi)置不需要額外裝客戶端。從ShardingSphere官網(wǎng)下載頁找最新穩(wěn)定版二進制包如果本地沒有就直接用內(nèi)網(wǎng)鏡像包名大致是apache-shardingsphere-xxx-bin.tar.gz。這里提供一個選版本的原則不追求最新選已經(jīng)發(fā)布超過半年的穩(wěn)定版本社區(qū)的issue和坑基本都被踩平了文檔也最齊。解壓后目錄結(jié)構(gòu)很清晰bin目錄是啟停腳本conf目錄放所有配置lib目錄是各種依賴jar包。整個中間件的設計思路是“配置驅(qū)動”你要改的一切都在conf下完成。我第一次部署時最不適應的一點是它沒有一個交互式控制臺讓你敲命令建庫建表一切都要通過YAML配置來聲明改完重啟進程生效。理解了這個模式之后反而覺得它適合自動化運維配完直接走配置管理流程發(fā)布即可。3.2 配置server.yaml賬號權(quán)限與全局參數(shù)conf/server.yaml是Proxy自身的基礎配置相當于這個“虛擬數(shù)據(jù)庫”的全局總控。最核心的是用戶認證信息這里決定了客戶端用哪個賬號密碼能連上來。rules: - !AUTHORITY users: - root%:root - sharding%:sharding provider: type: ALL_PERMISSIONS props: max-connections-size-per-query: 1 sql-show: true check-table-metadata-enabled: falseroot%:root的意思是用戶名root允許任意主機連接密碼是root。%表示來源IP不限生產(chǎn)環(huán)境建議改成具體網(wǎng)段。sql-show: true會把每條經(jīng)過Proxy的SQL打印到日志里排障時非常好用但生產(chǎn)環(huán)境建議關掉否則日志量會非?？捎^。max-connections-size-per-query表示一次查詢最多允許在多少物理庫上同時執(zhí)行1表示每個查詢路由到單庫執(zhí)行如果路由到多庫則串行這個參數(shù)直接關系到并發(fā)和連接占用后面性能章節(jié)再展開講。需要注意一個容易踩的坑如果下面想配合讀寫分離還需要在server.yaml里配置!TRANSACTION類型的全局事務規(guī)則如果不想用分布式事務保持默認即可。啟動前可以先用bin/start.bat這個腳本在Windows環(huán)境做快速驗證線上還是用bin/start.sh。3.3 配置config-sharding.yaml定義數(shù)據(jù)源和分片規(guī)則重頭戲在conf/config-sharding.yaml這里要定義邏輯庫、物理數(shù)據(jù)源、分片規(guī)則三大部分。先看數(shù)據(jù)源配置databaseName: sharding_db dataSources: ds0: url: jdbc:mysql://127.0.0.1:3306/demo_ds0?serverTimezoneUTCuseSSLfalse username: root password: root ds1: url: jdbc:mysql://127.0.0.1:3307/demo_ds1?serverTimezoneUTCuseSSLfalse username: root password: root注意兩個細節(jié)。一是連接串里的serverTimezoneUTC必填否則連接MySQL 8.x的時候會報時區(qū)錯誤二是useSSLfalse內(nèi)網(wǎng)環(huán)境沒必要做SSL握手加了這個參數(shù)能省掉一層握手耗時。模擬環(huán)境里我會把ds0和ds1配置成兩個真正的MySQL實例如果只有一臺機器可以用兩個不同端口模擬。接著是分片規(guī)則這是整個配置的靈魂rules: - !SHARDING tables: t_order: actualDataNodes: ds$-{0..1}.t_order_$-{0..3} tableStrategy: standard: shardingColumn: order_id shardingAlgorithmName: t_order_inline keyGenerateStrategy: column: order_id keyGeneratorName: snowflake shardingAlgorithms: t_order_inline: type: INLINE props: algorithm-expression: t_order_$-{order_id % 4} ds_inline: type: INLINE props: algorithm-expression: ds$-{user_id % 2} defaultDatabaseStrategy: standard: shardingColumn: user_id shardingAlgorithmName: ds_inline這里解釋一下每一行的作用。actualDataNodes聲明了t_order這個邏輯表對應的物理表位置ds$-{0..1}表示ds0和ds1兩個庫t_order_$-{0..3}表示每個庫里的4張物理表一共8張表。tableStrategy配置表級別的分片策略按order_id對4取模決定數(shù)據(jù)落在哪張物理表。defaultDatabaseStrategy配置庫級別的分片策略按user_id對2取模決定數(shù)據(jù)落在哪個物理庫。有個設計細節(jié)值得留意庫分片鍵我選了user_id而不是order_id。因為訂單場景里絕大部分查詢都是“查某個用戶的訂單”用user_id做庫分片能讓同一用戶的所有訂單都落在同一個物理庫后續(xù)查用戶訂單列表時只需要路由到一個庫不需要跨庫聚合。這是從業(yè)務查詢模式反推分片鍵的典型案例遠比“隨便找個字段取?！币煽?。3.4 啟動、建表、驗證查詢配置寫完后先確認兩個物理庫里已經(jīng)建好對應的物理表。ShardingProxy不會幫你自動建表需要你提前在ds0和ds1中分別執(zhí)行建表SQL把所有t_order_0到t_order_3都建出來。很多新手在這里栽跟頭Proxy配置的是8張實際表結(jié)果物理庫里只有一張t_order一查就報“表不存在”。啟動進程cd /opt/shardingsphere/bin ./start.sh tail -f ../logs/stdout.log看到類似ShardingSphere-Proxy memory mode started successfully的日志說明啟動成功。默認監(jiān)聽3307端口這個設計是故意的就是為了避開MySQL默認的3306端口防止連錯。如果用防火墻記得放行3307。然后用任意MySQL客戶端驗證mysql -h127.0.0.1 -P3307 -uroot -proot進入后執(zhí)行USE sharding_db再執(zhí)行一條插入和一條查詢。如果開啟了sql-show你會在日志里看到Proxy自動改寫后的SQL比如INSERT INTO t_order ...被改寫成對ds0下的t_order_1執(zhí)行這就是透明路由生效的證據(jù)。我第一次跑通時最深的感受是從外部看它就像一個安裝完就能用的MySQL完全不需要業(yè)務方理解后臺的復雜度。這種“低門檻接入”才是Proxy產(chǎn)品設計的核心價值。4. 讀寫分離與分布式事務讓Proxy更貼近生產(chǎn)4.1 讀寫分離配置與主從延遲問題真實的業(yè)務系統(tǒng)基本不會只用一臺數(shù)據(jù)庫主從架構(gòu)是標配。ShardingProxy在同一個配置體系里支持讀寫分離。在config-readwrite-splitting.yaml里定義邏輯數(shù)據(jù)源把寫庫和讀庫的關系告訴ProxydatabaseName: readwrite_splitting_db dataSources: write_ds: url: jdbc:mysql://127.0.0.1:3306/write_db username: root password: root read_ds_0: url: jdbc:mysql://127.0.0.1:3307/read_db username: root password: root rules: - !READWRITE_SPLITTING dataSources: readwrite_ds: writeDataSourceName: write_ds readDataSourceNames: - read_ds_0 loadBalancerName: round_robin loadBalancers: round_robin: type: ROUND_ROBIN使用的時候這個邏輯數(shù)據(jù)源readwrite_ds本身也可以繼續(xù)參與分片配置也就是說讀寫分離和分庫分表可以疊加使用。生產(chǎn)環(huán)境中常見的問題是“主從延遲”寫完主庫立刻去查數(shù)據(jù)還沒同步到從庫讀到舊數(shù)據(jù)。解決方案通常是在Proxy上層加一個強制路由提示或者業(yè)務層對剛寫完的數(shù)據(jù)做特殊處理。ShardingProxy可以通過Slave選主庫強制走寫庫執(zhí)行具體實現(xiàn)依賴SQL解析器的注釋透傳能力。我的建議是對一致性要求極高的場景不要依賴讀寫分離走寫庫最穩(wěn)妥報表、列表這類讀多寫少的業(yè)務才適合把只讀流量打到從庫。4.2 分布式事務類型與取舍分庫分表之后跨庫事務是個繞不開的坎。原來在單庫里的一條事務如果涉及到兩個物理庫普通的數(shù)據(jù)庫事務已經(jīng)無能為力了。ShardingProxy提供兩種方案XA事務和Seata柔性事務。XA是強一致的典型代表它的思路是事務管理器統(tǒng)一協(xié)調(diào)所有分片節(jié)點先預提交再統(tǒng)一提交保證要么全成功要么全失敗。配置方式在server.yaml里聲明事務類型為XA即可。XA的優(yōu)點是對業(yè)務透明接入成本低缺點是并發(fā)性能損耗比較大因為事務期間所有節(jié)點都要持有鎖等待協(xié)調(diào)者決定最終結(jié)果。Seata柔性事務則走的是最終一致路線業(yè)務上先做本地事務通過undo_log記錄反向操作遇到異常時反向補償回滾。Seata方案并發(fā)能力更強但需要額外部署Seata服務端同時業(yè)務代碼中需要引入相應的注解配合。我個人的選型經(jīng)驗是金融交易、賬戶類、庫存類這些強一致場景上XA寧可性能差點也不能出錯積分、日志、通知這類可以容忍短暫不一致的場景上Seata吞吐量高得多。最理想的情況是盡量從業(yè)務設計上避免跨庫事務比如把強關聯(lián)的表按照相同分片鍵放在同一物理庫事務就退化為單庫事務這是最高效的“分布式事務優(yōu)化方案”。4.3 多分片鍵與自定義算法擴展標準取模算法覆蓋了大多數(shù)場景但總有些業(yè)務需要更復雜的路由邏輯。比如訂單系統(tǒng)一天的數(shù)據(jù)量差異非常大大促期間可能是平時的幾十倍單純?nèi)∧е旅總€分片數(shù)據(jù)不均衡。這時候可以自定義分片算法。ShardingProxy的擴展機制基于SPI要做的是寫一個Java類實現(xiàn)對應的分片算法接口打成jar包放到lib目錄然后重啟Proxy。比如我可以實現(xiàn)一個結(jié)合“日期用戶ID末位”的復合分片算法每天的流量先按日分表再按用戶取模散到不同庫既能應對大促擴容單日表又能讓單日內(nèi)的數(shù)據(jù)分布均勻。這里要重點提醒自定義算法一旦上線后續(xù)想改路由邏輯會極其痛苦因為老數(shù)據(jù)已經(jīng)按照舊規(guī)則分布了。所以自定義算法在正式啟用前務必做充分的容量估算和回放測試。任何分片算法上線后都做“只讀增加、不輕易修改”的原則。5. 性能調(diào)優(yōu)與連接管理心得5.1 連接數(shù)與并發(fā)參數(shù)來自一場壓測的教訓之前幫一個團隊做過一次壓測場景是模擬1000個并發(fā)用戶同時查訂單。上線前測試環(huán)境一切正常一上生產(chǎn)就頻繁報Too many connections。查下來才發(fā)現(xiàn)問題出在Proxy和后端數(shù)據(jù)庫的連接數(shù)量匹配上。ShardingProxy本身面向每一個客戶端連接它還會根據(jù)SQL路由結(jié)果向后端數(shù)據(jù)庫發(fā)起連接。假如前端有100個連接每一條SQL同時路由到4個分片那么后端瞬間要建立400個連接。如果不限制max-connections-size-per-query后端數(shù)據(jù)庫的連接池直接被擊穿。我建議壓測前把max-connections-size-per-query設成1讓每個查詢路由到多個分片時串行執(zhí)行這樣后端連接數(shù)始終被控制在合理范圍。當然這會犧牲一些查詢速度所以這個參數(shù)應該在理解了“并發(fā)查詢數(shù)×單查詢節(jié)點數(shù)”的關系后根據(jù)后端數(shù)據(jù)庫能承受的連接總量來折中設置。后端MySQL的max_connections也要同步調(diào)大同時Proxy的JVM堆內(nèi)存建議至少給4-8G具體取決于路由聚合時的數(shù)據(jù)量。5.2 SQL解析開銷與日志陷阱很多人問Proxy會不會成為性能瓶頸答案是它確實有開銷但比大多數(shù)人想象的小得多。SQL解析、路由計算、結(jié)果合并這些操作都是在JVM內(nèi)存中完成的單核處理幾萬條簡單SQL沒什么問題。真正的性能殺手有兩個一個是大結(jié)果集跨分片合并另一個是日志?？绶制酆吓判蜻@種SQL比如LIMIT ORDER BYProxy需要把每個分片查到的數(shù)據(jù)全部拉到中間件內(nèi)存排序后再返回前端。如果單頁數(shù)據(jù)量太大內(nèi)存會直接飆高。我遇到過一個案例一張表分片后沒做任何優(yōu)化前端做分頁查詢每頁100條但Proxy內(nèi)存持續(xù)不釋放原因是Proxy為了排序要把所有符合條件的數(shù)據(jù)都加載進來。解決辦法是業(yè)務SQL加上明確的分片鍵條件讓路由收斂到單分片或者用NoSQL思路做寬表冗余避免跨分片聚合。日志問題說起來很基礎但很多人會中招sql-show: true在生產(chǎn)環(huán)境跑了一周發(fā)現(xiàn)日志文件幾個GB磁盤滿系統(tǒng)卡死。教訓就是這個參數(shù)只適合聯(lián)調(diào)和測試環(huán)境生產(chǎn)必須關掉實在要監(jiān)控可以通過接入Prometheus和JMX監(jiān)控指標來做。5.3 減少不必要的路由廣播可能遇到的另一個性能問題是SQL里明明帶了分片鍵但Proxy還是做了全路由。有一次排查慢查詢發(fā)現(xiàn)SQL里的分片鍵被包在函數(shù)里了比如WHERE DATE_FORMAT(create_time, %Y-%m-%d) 2024-01-01雖然create_time是分片鍵但經(jīng)過函數(shù)處理后Proxy無法提取分片鍵值只能廣播到所有分片。這不是Proxy的bug而是SQL規(guī)范化帶來的天然限制。想讓路由精準命中分片SQL里要“裸用”分片鍵中間不要套函數(shù)、不要做類型轉(zhuǎn)換。這是我多年實戰(zhàn)排障中反復驗證過的規(guī)律屬于典型的“中間件替你干活但你得遵守它的規(guī)則”。6. 常見問題與排查技巧實錄6.1 啟動失敗類端口、配置、驅(qū)動端口被占用是最常見的啟動失敗原因。ShardingProxy默認3307端口如果被其他進程占了啟動日志會報Address already in use。檢查端口占用后要么殺掉舊進程要么修改server.yaml里的port配置。配置語法錯誤比端口問題更隱蔽。YAML文件對縮進極其敏感尤其是rules節(jié)點下的- !SHARDING這樣的標簽少一個空格都會導致啟動失敗。我習慣在本地用支持YAML校驗的編輯器先格式化一遍再上傳能省下大量排錯時間。MySQL驅(qū)動不兼容是另一個高頻問題。如果連的是MySQL 8.xProxy內(nèi)置的驅(qū)動版本必須匹配否則會出現(xiàn)Unable to load authentication plugin caching_sha2_password之類的報錯。解決辦法是把用戶認證方式改成mysql_native_password或者升級Proxy到新版。PostgreSQL場景一般沒這個問題驅(qū)動內(nèi)置得比較完善。6.2 查詢報錯類邏輯庫不存在、表不存在啟動成功后客戶端連不上最常見的原因是連接時沒帶邏輯庫名。如果連接串寫的是jdbc:mysql://127.0.0.1:3307/而不是/sharding_dbProxy不知道你要用哪個邏輯庫直接報錯。這和原生MySQL不太一樣因為Proxy可以同時掛載多個邏輯庫必須明確指定。查詢時報“表不存在”先確認物理庫里是否真的建了對應的物理表。Proxy只負責路由不負責幫你建表。我見過不止一次配置里寫了t_order_$-{0..3}但物理庫只建了t_order_0一張表業(yè)務一查就炸。建議寫一個初始化腳本把所有分片表一次性建好順便做一次遍歷校驗。6.3 獨家避坑經(jīng)驗配置生命周期與灰度切換最后分享一個我特別想強調(diào)的經(jīng)驗ShardingProxy的配置變更至少在默認內(nèi)存模式下是需要重啟進程才生效的。重啟意味著所有在線連接會斷開對生產(chǎn)業(yè)務來說這是不可接受的。所以我的建議是把Proxy納入配置管理平臺變更時間窗選在業(yè)務低峰同時準備好回滾版本。如果項目對可用性要求極高可以考慮ShardingSphere后續(xù)版本里支持的集群模式把配置放到注冊中心統(tǒng)一管理配合管理端做動態(tài)生效。不過引入這個方案本身也增加了部署復雜度建議在資源允許的前提下再上。另外接入Proxy之前務必先在測試環(huán)境做一輪全量SQL兼容性測試重點覆蓋子查詢、多表JOIN、批量INSERT、分頁排序這四類SQL。它們是最容易觸發(fā)路由異常和結(jié)果合并bug的場景。把這個測試做扎實上線后至少能躲掉80%的坑。6.4 我常用的排障路徑遇到問題我會按照“連接層→路由層→執(zhí)行層→合并層”的順序來定位。連接層看端口、賬號、防火墻路由層開sql-show看改寫后的SQL是否落在預期分片執(zhí)行層去物理庫手動執(zhí)行改寫后的SQL確認物理庫本身沒問題合并層看返回結(jié)果集是否和預期一致。這套路徑幫我解決過幾十個疑難問題比亂猜高效得多。寫到最后想補充的一句話ShardingProxy不是那種用完就能立刻感受到“快”的組件它的價值是讓分庫分表后的系統(tǒng)依然像一個普通數(shù)據(jù)庫一樣可被消費。我在多個項目里體會最深的一點是中間件只是工具真正決定架構(gòu)成敗的是你對業(yè)務查詢模式的理解以及是否提前規(guī)劃好分片鍵、綁定表、廣播表和讀寫分離的組合策略。先把這些基礎打牢再上手Proxy你會發(fā)現(xiàn)很多問題不需要靠文檔看一眼配置就能想明白原因。