1. 從單庫單表到分庫分表為什么你的數(shù)據(jù)庫會“撐不住”做后端開發(fā)或者運(yùn)維的朋友可能都經(jīng)歷過這樣一個階段項(xiàng)目初期一個數(shù)據(jù)庫幾張表所有數(shù)據(jù)往里一扔增刪改查天下太平。但隨著業(yè)務(wù)像滾雪球一樣越滾越大用戶量、訂單量、數(shù)據(jù)量開始指數(shù)級增長你發(fā)現(xiàn)那個曾經(jīng)可靠的數(shù)據(jù)庫開始變得“力不從心”。最直觀的感受就是接口響應(yīng)越來越慢數(shù)據(jù)庫服務(wù)器的CPU和IO長期處于高位甚至?xí)r不時來個“連接數(shù)耗盡”的告警讓你半夜從床上彈起來。這時候你聽到最多的一個解決方案可能就是該考慮分庫分表了。分庫分表聽起來像是個“高級”話題很多資料一上來就講各種算法、中間件讓人望而生畏。但它的核心邏輯其實(shí)非常樸素當(dāng)一輛卡車裝不下所有貨物時我們就需要更多的卡車分庫或者把貨物拆成小份分別裝車分表。今天我就結(jié)合自己這些年處理過的大數(shù)據(jù)量場景拋開那些復(fù)雜的理論用最直白的方式帶你搞懂分庫分表的“為什么”、“是什么”和“怎么做”。你會發(fā)現(xiàn)它并沒有想象中那么神秘關(guān)鍵是要理解其背后的業(yè)務(wù)驅(qū)動和設(shè)計權(quán)衡。簡單來說分庫分表是為了解決數(shù)據(jù)庫的三大核心瓶頸性能瓶頸、可用性瓶頸和運(yùn)維瓶頸。性能瓶頸體現(xiàn)在單機(jī)處理能力有限連接數(shù)、CPU、IO、磁盤容量都會成為天花板可用性瓶頸是指單點(diǎn)故障一個庫掛了整個服務(wù)就不可用運(yùn)維瓶頸則是指數(shù)據(jù)量太大后備份、恢復(fù)、DDL變更如加索引、改字段變得極其困難且風(fēng)險極高。分庫分表就是通過水平拆分?jǐn)?shù)據(jù)將壓力分散到多個數(shù)據(jù)庫實(shí)例和表上從而系統(tǒng)性解決這些問題。2. 分庫、分表與分庫分表三種拆分模式的本質(zhì)區(qū)別在動手之前我們必須先厘清幾個基本概念。很多人會把分庫和分表混為一談其實(shí)它們解決的問題側(cè)重點(diǎn)不同組合起來就是分庫分表。2.1 垂直分表把“寬表”變“瘦”這通常是拆分的第一步不涉及分布式只在同一個數(shù)據(jù)庫內(nèi)進(jìn)行。想象一張用戶表包含了用戶基礎(chǔ)信息ID、姓名、手機(jī)、登錄信息密碼、鹽、擴(kuò)展信息頭像、簡介、標(biāo)簽以及一些不常更新的審計字段創(chuàng)建時間、更新時間。這張表很“寬”每次查詢即使只需要用戶名和手機(jī)號數(shù)據(jù)庫也需要把整行數(shù)據(jù)包含可能很大的頭像字段從磁盤讀到內(nèi)存。垂直分表的做法就是根據(jù)字段的訪問頻次和業(yè)務(wù)歸屬把一張大表拆分成多張小表。比如user_base存放高頻訪問的核心字段user_id, name, mobile。user_auth存放安全相關(guān)的敏感字段user_id, password, salt。user_profile存放低頻訪問的擴(kuò)展字段user_id, avatar, bio, tags。user_audit存放審計字段user_id, created_at, updated_at。它們通過共同的user_id主鍵關(guān)聯(lián)。這樣做的好處是提升高頻查詢性能查詢用戶基礎(chǔ)信息時只需要掃描更小的user_base表IO效率更高內(nèi)存中能緩存更多熱點(diǎn)數(shù)據(jù)。實(shí)現(xiàn)冷熱數(shù)據(jù)分離將大字段、低頻字段剝離避免其影響核心業(yè)務(wù)的查詢效率。便于安全管理可以將包含密碼的表單獨(dú)放在更安全的存儲或進(jìn)行特殊加密處理。注意事項(xiàng)垂直分表后原本一次SELECT *就能拿到的數(shù)據(jù)現(xiàn)在可能需要JOIN多張表。因此它通常需要業(yè)務(wù)層配合根據(jù)查詢場景決定訪問哪些表或者通過冗余字段來避免關(guān)聯(lián)查詢。它不能解決單表數(shù)據(jù)行數(shù)過多的問題。2.2 水平分表解決單表數(shù)據(jù)量膨脹這是應(yīng)對海量數(shù)據(jù)最核心的手段。當(dāng)單表數(shù)據(jù)達(dá)到千萬甚至億級即使字段不多B樹索引的深度也會增加查詢性能下降寫入也會成為瓶頸。水平分表就是把一張表的數(shù)據(jù)按某種規(guī)則路由鍵拆分到多個結(jié)構(gòu)完全相同的表中。例如原始的order表有10億條數(shù)據(jù)。我們按order_id訂單ID的范圍進(jìn)行拆分order_0000存儲 order_id 在 1-1000萬的訂單。order_0001存儲 order_id 在 1000萬-2000萬的訂單。...order_0099存儲 order_id 在 9.9億-10億的訂單。這樣每個分表的數(shù)據(jù)量就降到了1000萬查詢和寫入的壓力被分散到了100張物理表上。對于數(shù)據(jù)庫實(shí)例來說這些表還在同一個庫里所以它主要解決的是單表數(shù)據(jù)量過大的問題對連接數(shù)、CPU等單庫瓶頸緩解有限。2.3 分庫從根本上分散數(shù)據(jù)庫壓力分庫就是將數(shù)據(jù)分布到不同的數(shù)據(jù)庫實(shí)例可能在不同服務(wù)器上。它可以是垂直分庫也可以是水平分庫。垂直分庫按業(yè)務(wù)模塊拆分。比如將用戶相關(guān)的表放在user_db訂單相關(guān)的表放在order_db商品相關(guān)的表放在product_db。這能有效隔離不同業(yè)務(wù)間的資源競爭便于專庫專用、獨(dú)立擴(kuò)容。水平分庫是水平分表的進(jìn)階版。將一張表的數(shù)據(jù)拆分到多個數(shù)據(jù)庫的多個表中。例如order表的數(shù)據(jù)被分散到db_0庫的order_0表、db_1庫的order_1表……中。分庫分表通常就是指水平分庫水平分表這是最徹底的拆分方案。它同時解決了單表數(shù)據(jù)量大和單庫實(shí)例瓶頸的問題。但復(fù)雜度也最高因?yàn)閿?shù)據(jù)被分散在多個物理節(jié)點(diǎn)上跨庫事務(wù)、全局查詢、分布式ID生成等問題隨之而來。3. 如何選擇路由鍵拆分策略的靈魂所在決定了要分庫分表下一個最關(guān)鍵的問題就是按什么規(guī)則來拆分?jǐn)?shù)據(jù)這個規(guī)則依賴的字段就是“路由鍵”或“分片鍵”。路由鍵的選擇直接決定了數(shù)據(jù)分布的均勻性、查詢的便捷性以及未來的擴(kuò)展性是設(shè)計中最需要深思熟慮的一環(huán)。3.1 常見路由策略深度解析1. 范圍分片按路由鍵的連續(xù)區(qū)間進(jìn)行劃分如用戶ID從1-1000萬在分片11000萬-2000萬在分片2。優(yōu)點(diǎn)范圍查詢效率高如WHERE user_id BETWEEN 100 AND 200因?yàn)閿?shù)據(jù)在物理上是相鄰的。缺點(diǎn)容易產(chǎn)生“熱點(diǎn)”。如果按時間如創(chuàng)建月份分片當(dāng)前活躍數(shù)據(jù)永遠(yuǎn)集中在最新的一個分片上造成該分片負(fù)載遠(yuǎn)高于其他。數(shù)據(jù)分布也可能不均需要定期調(diào)整邊界。適用場景有明顯冷熱數(shù)據(jù)區(qū)分且可以對冷數(shù)據(jù)進(jìn)行歸檔的業(yè)務(wù)?；蛘呗酚涉I本身是連續(xù)且增長均勻的序列。2. 哈希分片對路由鍵取哈希值如MD5、CRC32然后用哈希值對分片總數(shù)取模決定數(shù)據(jù)落在哪個分片。優(yōu)點(diǎn)數(shù)據(jù)分布均勻能有效避免熱點(diǎn)問題。缺點(diǎn)范圍查詢和排序操作會變成災(zāi)難。因?yàn)楣４蛏⒘藬?shù)據(jù)的連續(xù)性一個簡單的WHERE user_id 1000查詢需要向所有分片發(fā)送請求并聚合結(jié)果性能極差。另外一旦確定分片數(shù)量后期擴(kuò)容增加分片非常麻煩需要重新哈希并遷移大量數(shù)據(jù)。適用場景點(diǎn)查詢按ID查為主極少有范圍查詢需求的業(yè)務(wù)。例如通過訂單號查詢訂單詳情。3. 一致性哈希分片這是對普通哈希的優(yōu)化常用于分布式緩存如Redis Cluster。它將哈?？臻g組織成一個環(huán)數(shù)據(jù)和分片節(jié)點(diǎn)都映射到環(huán)上數(shù)據(jù)按順時針方向找到第一個節(jié)點(diǎn)。當(dāng)增加或刪除節(jié)點(diǎn)時只影響環(huán)上相鄰部分的數(shù)據(jù)避免了全量數(shù)據(jù)重新哈希。優(yōu)點(diǎn)擴(kuò)容縮容時數(shù)據(jù)遷移量小對系統(tǒng)影響小。缺點(diǎn)實(shí)現(xiàn)相對復(fù)雜且依然無法支持范圍查詢。適用場景需要頻繁彈性擴(kuò)縮容的分布式存儲系統(tǒng)。4. 地理位置分片按用戶或數(shù)據(jù)的所屬地區(qū)分片。例如華北用戶的數(shù)據(jù)放在北京機(jī)房華南用戶的數(shù)據(jù)放在深圳機(jī)房。優(yōu)點(diǎn)符合業(yè)務(wù)特征能實(shí)現(xiàn)數(shù)據(jù)就近訪問降低網(wǎng)絡(luò)延遲。缺點(diǎn)如果用戶流動性大或者業(yè)務(wù)需要全局視圖會比較麻煩。適用場景業(yè)務(wù)有明顯地域性且跨地域數(shù)據(jù)交互需求少的應(yīng)用如本地生活服務(wù)。5. 業(yè)務(wù)鍵分片使用業(yè)務(wù)中有明確意義的字段組合進(jìn)行分片。例如對于一個電商平臺按商戶ID分庫再按訂單創(chuàng)建日期分表。這樣同一個商戶的所有訂單在物理上會相對集中可能在同一庫或相鄰庫。優(yōu)點(diǎn)能很好地支持業(yè)務(wù)內(nèi)的常見查詢模式。比如商戶查自己所有訂單只需要訪問特定分片效率高。缺點(diǎn)設(shè)計難度大需要深刻理解業(yè)務(wù)查詢模式。如果業(yè)務(wù)模式發(fā)生變化分片策略可能失效。適用場景業(yè)務(wù)模型穩(wěn)定核心查詢路徑清晰的系統(tǒng)。3.2 路由鍵選擇的核心原則與避坑指南從我踩過的坑來看選擇路由鍵務(wù)必遵循以下原則離散性優(yōu)先盡量選擇值分布均勻、離散度高的字段作為路由鍵如用戶ID、訂單SN序列號。避免使用枚舉值少或可能產(chǎn)生傾斜的字段如“訂單狀態(tài)”大部分訂單最終都是“已完成”狀態(tài)。查詢攜帶原則你的核心查詢條件必須包含路由鍵。因?yàn)榉謳旆直砗笙到y(tǒng)需要根據(jù)查詢條件中的路由鍵值快速定位數(shù)據(jù)在哪個分片。如果查詢條件不帶路由鍵就會觸發(fā)“全分片掃描”廣播查詢性能極差。例如你按user_id分片但業(yè)務(wù)中卻經(jīng)常需要根據(jù)user_email來查詢這就成了災(zāi)難。解決辦法通常是在user_email上建立全局二級索引另一套映射關(guān)系或者進(jìn)行數(shù)據(jù)冗余。避免跨分片事務(wù)盡量讓一個事務(wù)內(nèi)涉及的數(shù)據(jù)落在同一個分片。例如創(chuàng)建訂單時訂單主表和訂單商品明細(xì)表最好使用相同的路由鍵如order_id確保它們在同一分片可以用本地事務(wù)保證一致性。否則就需要引入復(fù)雜的分布式事務(wù)方案如Seata成本陡增?？紤]未來擴(kuò)展初期設(shè)計時要為分片數(shù)量留有余量。比如雖然現(xiàn)在只用2個分片但可以在路由算法中設(shè)計為對16取模未來可以平滑擴(kuò)容到4、8、16個分片。這就是“提前規(guī)劃分片容量”。一個真實(shí)的踩坑案例早期我們按用戶ID的哈希分片業(yè)務(wù)發(fā)展很快。后來需要增加“根據(jù)手機(jī)號查詢用戶”的功能而手機(jī)號并不在路由鍵中。臨時方案是在業(yè)務(wù)代碼里遍歷所有分片查詢性能慘不忍睹。最終不得不重構(gòu)引入了基于手機(jī)號的全局查詢索引表代價巨大。這個教訓(xùn)告訴我們設(shè)計之初就要盡可能預(yù)判未來的核心查詢路徑。4. 分庫分表后的挑戰(zhàn)與應(yīng)對之道分庫分表不是銀彈它把單機(jī)數(shù)據(jù)庫的問題轉(zhuǎn)化成了一組分布式系統(tǒng)的問題。下面這些挑戰(zhàn)是你在實(shí)施前就必須想好對策的。4.1 分布式全局唯一ID生成單庫時我們依賴數(shù)據(jù)庫的自增主鍵AUTO_INCREMENT。分庫分表后多個節(jié)點(diǎn)同時生成ID自增主鍵會導(dǎo)致沖突。必須有一個全局唯一的ID生成方案。主流方案有UUID本地生成絕對唯一但長度長36字符、無序作為數(shù)據(jù)庫主鍵插入時會導(dǎo)致B樹頻繁分裂嚴(yán)重影響寫入性能一般不推薦。數(shù)據(jù)庫號段模式用一個獨(dú)立的數(shù)據(jù)庫表來分配ID號段。例如服務(wù)每次從數(shù)據(jù)庫獲取一個號段如1-1000用完后再次申請。性能好趨勢遞增但存在單點(diǎn)故障風(fēng)險可通過多主模式緩解。Snowflake算法Twitter開源的算法生成一個64位的Long型ID包含時間戳、工作機(jī)器ID、序列號。本地生成高性能趨勢遞增。這是目前最主流、最推薦的方案。但需要注意機(jī)器ID的分配管理以及時鐘回?fù)軉栴}服務(wù)器時間發(fā)生倒退的處理。Redis INCR利用Redis的原子遞增命令生成ID性能極高。但同樣有Redis單點(diǎn)/集群維護(hù)的問題且生成的ID連續(xù)性過強(qiáng)可能暴露業(yè)務(wù)量信息。實(shí)操建議對于絕大多數(shù)國內(nèi)互聯(lián)網(wǎng)應(yīng)用直接使用優(yōu)化過的Snowflake變種如美團(tuán)的Leaf、百度的UidGenerator是最穩(wěn)妥的選擇。它們通常解決了時鐘回?fù)艿葐栴}并提供了開箱即用的客戶端。4.2 跨分片查詢與聚合分庫分表后SELECT * FROM order這種查詢需要從所有分片獲取數(shù)據(jù)然后在內(nèi)存中聚合。分頁查詢LIMIT 10, 20會變得異常復(fù)雜因?yàn)槟阈枰獜拿總€分片取回數(shù)據(jù)在內(nèi)存中排序后再取出第10到30條。聚合函數(shù)如COUNT(),SUM(),AVG()也需要在所有分片上執(zhí)行后再匯總。應(yīng)對策略從業(yè)務(wù)上規(guī)避這是上策。重新設(shè)計查詢使其帶上路由鍵從而定位到單個分片。例如將“查詢所有訂單”改為“查詢某用戶的訂單”。建立異步匯總表對于需要全局統(tǒng)計的指標(biāo)如總交易額通過Binlog監(jiān)聽數(shù)據(jù)變更異步計算并更新到一張單獨(dú)的匯總表中。查詢時直接查匯總表。使用中間件能力像ShardingSphere這類中間件提供了對跨分片查詢、聚合、分頁的有限支持。它會自動將邏輯SQL改寫下發(fā)到各個分片執(zhí)行并在內(nèi)存中完成結(jié)果合并。但這會消耗大量中間件內(nèi)存和網(wǎng)絡(luò)資源必須嚴(yán)格限制此類查詢的數(shù)據(jù)量。4.3 分布式事務(wù)“下單扣庫存”這類操作如果訂單表和庫存表被分到了不同的數(shù)據(jù)庫就無法再用簡單的數(shù)據(jù)庫本地事務(wù)來保證“要么都成功要么都失敗”。解決方案最終一致性這是互聯(lián)網(wǎng)分布式系統(tǒng)最常用的模式。放棄強(qiáng)一致性通過可靠消息隊列如RocketMQ和事務(wù)補(bǔ)償機(jī)制來實(shí)現(xiàn)最終一致。例如下單時先扣庫存然后發(fā)出一條“創(chuàng)建訂單”消息。訂單服務(wù)消費(fèi)消息創(chuàng)建訂單如果失敗則發(fā)出一條“釋放庫存”的補(bǔ)償消息。業(yè)務(wù)上需要容忍中間狀態(tài)的存在。TCC事務(wù)Try-Confirm-Cancel。每個參與者需要實(shí)現(xiàn)三個接口。性能較好但對業(yè)務(wù)侵入性強(qiáng)開發(fā)復(fù)雜。Seata AT模式基于全局鎖和undo_log實(shí)現(xiàn)對業(yè)務(wù)代碼侵入小通過注解但性能有一定損耗且對數(shù)據(jù)庫類型有要求。個人經(jīng)驗(yàn)除非是金融、交易等對強(qiáng)一致性要求極高的核心鏈路否則優(yōu)先考慮最終一致性方案。它架構(gòu)簡單吞吐量高更能適應(yīng)分布式環(huán)境。在設(shè)計業(yè)務(wù)時就要思考如何將事務(wù)邊界縮小或者設(shè)計出可補(bǔ)償?shù)臉I(yè)務(wù)流程。4.4 數(shù)據(jù)遷移與擴(kuò)容業(yè)務(wù)在增長今天的分片數(shù)量明天可能就不夠用了。如何平滑地從2個分片擴(kuò)展到4個分片雙寫遷移方案是目前最穩(wěn)妥的在線擴(kuò)容方案其核心步驟是雙寫階段在應(yīng)用代碼中對數(shù)據(jù)的增刪改操作同時寫入舊分片和新分片規(guī)則。此階段所有讀取操作仍然只走舊分片規(guī)則。這個階段需要持續(xù)一段時間確保舊數(shù)據(jù)被完全同步。數(shù)據(jù)遷移與校驗(yàn)啟動一個離線任務(wù)將舊分片的歷史數(shù)據(jù)按新的分片規(guī)則計算遷移到新的分片中。遷移完成后進(jìn)行數(shù)據(jù)一致性校驗(yàn)。讀切流將讀取流量逐步切換到新分片規(guī)則可以先從非核心業(yè)務(wù)或少量用戶開始灰度。寫切流與下線當(dāng)讀新分片完全穩(wěn)定后將寫流量也切換到新分片規(guī)則。穩(wěn)定運(yùn)行一段時間后下線舊分片的數(shù)據(jù)和雙寫邏輯。這個過程非?？简?yàn)自動化運(yùn)維能力和對一致性的把控任何一個環(huán)節(jié)出錯都可能導(dǎo)致數(shù)據(jù)錯亂。因此選擇支持在線彈性擴(kuò)容的中間件如某些云數(shù)據(jù)庫服務(wù)或者在一開始就預(yù)留足夠多的分片數(shù)量是更省心的做法。5. 技術(shù)選型客戶端中間件 vs. 服務(wù)端代理當(dāng)你決定實(shí)施分庫分表下一個問題就是如何讓應(yīng)用程序無感知或低感知地操作這些分散的數(shù)據(jù)這里主要有兩大技術(shù)路線。5.1 客戶端中間件架構(gòu)于應(yīng)用層代表產(chǎn)品Apache ShardingSphere-JDBC、TDDL阿里。工作原理以Jar包的形式嵌入到你的應(yīng)用程序中。它實(shí)現(xiàn)了JDBC接口對你的應(yīng)用來說它就像一個普通的數(shù)據(jù)庫驅(qū)動。應(yīng)用代碼寫的是邏輯SQL操作邏輯表orderShardingSphere-JDBC在運(yùn)行時根據(jù)配置的分片規(guī)則將SQL解析、改寫后路由到具體的物理分片order_001上執(zhí)行并將結(jié)果歸并返回。優(yōu)點(diǎn)性能高網(wǎng)絡(luò)開銷小因?yàn)槭侵边B數(shù)據(jù)庫沒有額外的代理跳轉(zhuǎn)。兼容性好支持任何兼容JDBC協(xié)議的數(shù)據(jù)庫。功能強(qiáng)大除了分片還提供了讀寫分離、數(shù)據(jù)加密、影子庫等豐富功能。部署簡單無需獨(dú)立部署中間件服務(wù)。缺點(diǎn)侵入性強(qiáng)需要項(xiàng)目引入其Jar包升級需要聯(lián)動應(yīng)用發(fā)布。多語言支持弱主要面向Java生態(tài)。其他語言需要各自版本的客戶端。消耗應(yīng)用資源SQL解析、改寫等計算消耗的是應(yīng)用服務(wù)器的CPU和內(nèi)存。升級困難版本升級需要所有接入應(yīng)用同步升級。5.2 服務(wù)端代理獨(dú)立部署的中間件代表產(chǎn)品Apache ShardingSphere-Proxy、MyCat、DBProxy。工作原理作為一個獨(dú)立的服務(wù)部署對外偽裝成一個MySQL數(shù)據(jù)庫。你的應(yīng)用程序像連接一個普通MySQL一樣連接Proxy。Proxy接收應(yīng)用的SQL請求完成分片路由等操作后再轉(zhuǎn)發(fā)給后端的真實(shí)數(shù)據(jù)庫并將結(jié)果返回給應(yīng)用。優(yōu)點(diǎn)對應(yīng)用零侵入應(yīng)用無需任何改造使用標(biāo)準(zhǔn)數(shù)據(jù)庫驅(qū)動即可。多語言支持任何能連接MySQL的語言Go, Python, PHP等都能直接使用。獨(dú)立升級中間件升級不影響業(yè)務(wù)應(yīng)用。便于監(jiān)控所有數(shù)據(jù)庫流量都經(jīng)過Proxy方便做統(tǒng)一的監(jiān)控、審計、限流。缺點(diǎn)性能有損耗多了一次網(wǎng)絡(luò)轉(zhuǎn)發(fā)存在單點(diǎn)瓶頸雖然Proxy本身可集群部署。運(yùn)維復(fù)雜度高需要額外維護(hù)一套高可用的Proxy集群。功能可能滯后某些高級的、定制化的SQL支持可能不如客戶端模式靈活。5.3 選型建議與個人心得如何選擇我的經(jīng)驗(yàn)是如果你的技術(shù)棧以Java為主且追求極致性能和更靈活的控制首選ShardingSphere-JDBC。它是目前社區(qū)最活躍、生態(tài)最完善的方案我們團(tuán)隊在生產(chǎn)環(huán)境大規(guī)模使用穩(wěn)定性經(jīng)受住了考驗(yàn)。它的“可插拔”架構(gòu)設(shè)計得很好可以根據(jù)需要引入分片、讀寫分離、數(shù)據(jù)加密等模塊。如果你的公司是多語言技術(shù)棧如同時有Java、Go、PHP服務(wù)或者不希望改造現(xiàn)有應(yīng)用代碼那么ShardingSphere-Proxy是更好的選擇。它可以作為整個公司的數(shù)據(jù)庫訪問入口統(tǒng)一管理。對于云上用戶直接使用云廠商提供的分布式數(shù)據(jù)庫服務(wù)如阿里云的PolarDB-X、騰訊云的TDSQL可能是最省事的。它們底層自動完成了分庫分表的細(xì)節(jié)對外提供標(biāo)準(zhǔn)的MySQL協(xié)議你幾乎可以像使用單機(jī)MySQL一樣使用它但代價是成本和廠商鎖定。一個關(guān)鍵的實(shí)操提醒無論選擇哪種中間件一定要在測試環(huán)境進(jìn)行完整的壓測。特別是要測試跨分片查詢、排序、分頁等復(fù)雜場景的性能評估中間件本身的內(nèi)存和CPU消耗。我們曾經(jīng)在未充分壓測的情況下上線結(jié)果一個不起眼的全局查詢在流量高峰時拖垮了中間件節(jié)點(diǎn)。6. 實(shí)戰(zhàn)基于ShardingSphere-JDBC的水平分表配置詳解理論說了這么多我們來看一個最簡單的實(shí)戰(zhàn)例子如何使用ShardingSphere-JDBC對一個訂單表進(jìn)行水平分表。假設(shè)我們有一張t_order表未來數(shù)據(jù)量會很大決定先進(jìn)行水平分表暫不分庫。目標(biāo)將t_order表拆分為4張物理表t_order_0,t_order_1,t_order_2,t_order_3。分片規(guī)則是根據(jù)訂單IDorder_id對4取模。步驟1引入依賴在你的Spring Boot項(xiàng)目的pom.xml中引入ShardingSphere-JDBC的Spring Boot Starter。dependency groupIdorg.apache.shardingsphere/groupId artifactIdshardingsphere-jdbc-core-spring-boot-starter/artifactId version5.3.2/version !-- 請使用最新穩(wěn)定版 -- /dependency步驟2準(zhǔn)備數(shù)據(jù)庫在同一個數(shù)據(jù)庫中創(chuàng)建4張結(jié)構(gòu)完全相同的物理表。CREATE TABLE t_order_0 ( order_id bigint(20) NOT NULL, user_id int(11) NOT NULL, amount decimal(10,2) DEFAULT NULL, status varchar(20) DEFAULT NULL, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (order_id) ) ENGINEInnoDB; -- 同樣創(chuàng)建 t_order_1, t_order_2, t_order_3步驟3配置分片規(guī)則application.yml這是最核心的一步。我們通過YAML文件告訴ShardingSphere如何分片。spring: shardingsphere: # 數(shù)據(jù)源配置這里我們只有一個物理庫ds0里面有多張分表 datasource: names: ds0 ds0: type: com.zaxxer.hikari.HikariDataSource driver-class-name: com.mysql.cj.jdbc.Driver jdbc-url: jdbc:mysql://localhost:3306/sharding_db?useUnicodetruecharacterEncodingutf8useSSLfalse username: root password: root # 分片規(guī)則配置 rules: sharding: # 配置分表規(guī)則 tables: # t_order 是邏輯表名 t_order: # 實(shí)際的數(shù)據(jù)節(jié)點(diǎn)格式數(shù)據(jù)源名.表名。這里表示ds0庫下的t_order_0到t_order_3四張表 actual-data-nodes: ds0.t_order_$-{0..3} # 分表策略 table-strategy: standard: # 分片列路由鍵 sharding-column: order_id # 分片算法這里使用行表達(dá)式。order_id % 4 的結(jié)果對應(yīng) $-{0..3} sharding-algorithm-name: t-order-inline # 定義分片算法 sharding-algorithms: t-order-inline: type: INLINE props: # 行表達(dá)式 groovy語法。${order_id % 4} 計算分片鍵的模結(jié)果映射到t_order_$-{result}表 algorithm-expression: t_order_$-{order_id % 4} # 是否在日志中打印SQL解析和改寫詳情調(diào)試時非常有用 props: sql-show: true步驟4編寫業(yè)務(wù)代碼配置完成后你的業(yè)務(wù)代碼完全不需要改變。你仍然像操作單表一樣操作t_order。Repository public class OrderRepository { Autowired private JdbcTemplate jdbcTemplate; // 插入訂單ShardingSphere會根據(jù)order_id的值自動路由到具體分表 public void insertOrder(Order order) { String sql INSERT INTO t_order (order_id, user_id, amount, status) VALUES (?, ?, ?, ?); jdbcTemplate.update(sql, order.getOrderId(), order.getUserId(), order.getAmount(), order.getStatus()); } // 根據(jù)order_id查詢會精準(zhǔn)路由到一個分表 public Order selectByOrderId(Long orderId) { String sql SELECT * FROM t_order WHERE order_id ?; return jdbcTemplate.queryForObject(sql, new BeanPropertyRowMapper(Order.class), orderId); } // 根據(jù)user_id查詢由于user_id不是分片鍵這條SQL會廣播到所有4張分表執(zhí)行全表掃描性能差 public ListOrder selectByUserId(Integer userId) { String sql SELECT * FROM t_order WHERE user_id ?; return jdbcTemplate.query(sql, new BeanPropertyRowMapper(Order.class), userId); } }步驟5驗(yàn)證與測試啟動應(yīng)用執(zhí)行插入操作。假設(shè)插入order_id1001的訂單由于1001 % 4 1數(shù)據(jù)會被插入到t_order_1表中。打開sql-show日志你會看到類似如下的輸出Logic SQL: INSERT INTO t_order (order_id, user_id, amount, status) VALUES (?, ?, ?, ?) Actual SQL: ds0 ::: INSERT INTO t_order_1 (order_id, user_id, amount, status) VALUES (?, ?, ?, ?)這說明ShardingSphere正確地將邏輯SQL改寫并路由到了具體的物理表。注意事項(xiàng)與進(jìn)階分布式ID示例中我們直接使用了order_id。在生產(chǎn)中你必須使用Snowflake等分布式ID生成器來生成order_id確保其全局唯一且趨勢遞增這對分片均勻性和數(shù)據(jù)庫插入性能友好。綁定表如果你還有一張t_order_item訂單明細(xì)表也需要按order_id分表且分片數(shù)與t_order相同。你需要將這兩張表配置為“綁定表”。這樣當(dāng)關(guān)聯(lián)查詢t_order o JOIN t_order_item i ON o.order_id i.order_id時ShardingSphere知道它們的分片規(guī)則一致會直接將關(guān)聯(lián)查詢下推到同一個分片執(zhí)行而不是進(jìn)行笛卡爾積式的全路由極大提升關(guān)聯(lián)查詢性能。廣播表像t_region地區(qū)表這種數(shù)據(jù)量小、所有分片都需要使用的維表可以配置為“廣播表”。寫入時數(shù)據(jù)會同步到所有分片查詢時任意分片都有全量數(shù)據(jù)。通過這個簡單的例子你可以看到借助成熟的中間件分庫分表的接入成本被大大降低了。但切記工具只是幫你解決了“怎么做”的問題而“為什么做”、“按什么分”這些設(shè)計層面的思考才是決定項(xiàng)目成敗的關(guān)鍵。在真正動手之前花足夠的時間梳理業(yè)務(wù)設(shè)計好路由鍵和拆分方案遠(yuǎn)比盲目選擇技術(shù)組件重要得多。