簡介本資源是一份面向Java后端開發(fā)者與數(shù)據(jù)庫架構初學者的分庫分表實戰(zhàn)教學包聚焦企業(yè)級大數(shù)據(jù)量場景下的數(shù)據(jù)庫水平擴展難題以Sharding-JDBC為核心框架實現(xiàn)多數(shù)據(jù)源動態(tài)切換與透明化分片。資源共73個文件涵蓋18個Java業(yè)務與配置類、21個編譯后class文件、18個XML配置與映射文件含MyBatis映射及Sharding規(guī)則定義以及SQL建表腳本、Maven項目配置pom.xml、Eclipse工程元數(shù)據(jù).project/.classpath等關鍵開發(fā)資產整體僅66KB輕量易導入。已有2068人學習下載適合快速搭建SSMDemo環(huán)境并理解分片路由、數(shù)據(jù)源初始化、YAML分片規(guī)則配置等核心實踐環(huán)節(jié)。讀者可直接復用項目結構掌握從多數(shù)據(jù)源聲明、分庫分表策略配置到跨庫CRUD調用的完整鏈路尤其適用于SpringMyBatisSharding-JDBC技術棧的中小規(guī)模分片落地參考。1. 分庫分表多數(shù)據(jù)源的切換不是加個注解就完事而是讓每個DAO層調用都清楚自己該連哪張表、哪個庫你剛接手一個日增300萬訂單的電商后臺MySQL單表已超2800萬行慢查詢從“偶發(fā)”變成“每分鐘必報”DBA甩來一句“上分庫分表吧?！薄Y果你興沖沖引入ShardingSphere配置好邏輯表、分片鍵、分片算法一跑測試發(fā)現(xiàn)用戶中心查user_info正常但訂單服務里一個帶JOIN的報表SQL直接報錯“無法路由到具體數(shù)據(jù)源”更玄學的是同一個Service方法里前半段insert走的是ds0后半段update卻連到了ds1事務根本沒法提交。這不是配置沒生效而是分庫分表的本質從來不是“自動拆分”而是“顯式聲明精準控制”。這個項目就是一套可落地、可調試、可驗證的多數(shù)據(jù)源切換實戰(zhàn)方案它不依賴黑匣子中間件的自動路由而是用Spring原生AbstractRoutingDataSource 自定義ThreadLocal上下文 顯式數(shù)據(jù)源標記把“哪個線程該用哪個庫”這件事從配置文件里拽出來寫進代碼里、打在日志里、壓測時能一眼看穿。適合正在被跨庫JOIN、讀寫分離、歷史庫歸檔、灰度發(fā)布數(shù)據(jù)隔離等問題卡住的后端開發(fā)者尤其適合那些已經(jīng)踩過ShardingSphere規(guī)則配置陷阱、想回歸可控性的團隊。2. 架構設計與核心模塊拆解三層路由機制讓數(shù)據(jù)源選擇不再靠猜這個項目不是簡單封裝了一個DynamicDataSource而是構建了上下文驅動 規(guī)則匹配 手動覆蓋的三級路由體系。它把“用哪個庫”這件事拆成三個可獨立驗證、可組合使用的環(huán)節(jié)最外層是業(yè)務語義標記比如TargetDataSource(write)中間層是分片鍵自動識別比如方法參數(shù)含userId且當前策略為user_id分片最內層是線程級強制綁定比如開啟事務時鎖定主庫。三者優(yōu)先級從高到低沖突時以手動標記為準。這種設計避免了“全局默認庫”帶來的隱式耦合也繞開了中間件對SQL語法的強約束——你寫原生MyBatis XML它照樣能路由你用JdbcTemplate手寫復雜UNION它也能按需切庫。整個結構輕量無額外jar依賴、透明所有路由決策可打日志、可測試Mock ThreadLocal即可覆蓋全部分支。2.1 核心路由引擎AbstractRoutingDataSource的深度定制Spring原生的AbstractRoutingDataSource只提供一個determineCurrentLookupKey()抽象方法返回String類型的key。但本項目在此基礎上做了三處關鍵增強key不再是簡單字符串而是自定義的DataSourceKey類包含type(READ/WRITE)、shardId(如shard_01)、sourceId(如ds_master_v2)三個維度determineCurrentLookupKey()內部不直接返回key而是委托給RouterChain執(zhí)行鏈式判斷每次key生成后自動記錄到MDC中供日志追蹤如[ds_keyWRITE:shard_01:ds_master_v2]。public class DynamicRoutingDataSource extends AbstractRoutingDataSource { Override protected Object determineCurrentLookupKey() { // 1. 檢查線程局部變量是否已強制綁定 DataSourceKey forcedKey DataSourceContextHolder.getForcedKey(); if (forcedKey ! null) { log.debug(Route forced: {}, forcedKey); return forcedKey; } // 2. 嘗試從方法參數(shù)/注解提取分片上下文 DataSourceKey contextKey ContextRouter.routeByContext(); if (contextKey ! null) { log.debug(Route by context: {}, contextKey); return contextKey; } // 3. 回退到默認策略如讀寫分離下的READ DataSourceKey defaultKey DefaultRouter.routeByDefault(); log.debug(Route by default: {}, defaultKey); return defaultKey; } }提示DataSourceKey必須實現(xiàn)equals()和hashCode()否則Spring緩存的targetDataSource Map會失效——這是血淚經(jīng)驗曾因忘記重寫導致同一key反復創(chuàng)建新連接池DB連接數(shù)暴增。2.2 上下文管理器ThreadLocal MDC雙保險DataSourceContextHolder是整個路由的“開關中樞”。它不只存一個String而是維護三個ThreadLocal變量forcedKey: 用于Transactional或TargetDataSource注解觸發(fā)的強制綁定shardContext: 存儲當前請求的分片標識如userId12345 → shardIdshard_03routeTrace: 布爾值開啟后自動記錄每次路由決策路徑用于排查“為什么沒走預期庫”。public class DataSourceContextHolder { private static final ThreadLocalDataSourceKey FORCED_KEY_HOLDER new NamedThreadLocal(forcedDataSourceKey); private static final ThreadLocalShardContext SHARD_CONTEXT_HOLDER new NamedThreadLocal(shardContext); private static final ThreadLocalBoolean ROUTE_TRACE_HOLDER ThreadLocal.withInitial(() - false); public static void setForcedKey(DataSourceKey key) { FORCED_KEY_HOLDER.set(key); // 同步寫入MDC確保日志可追溯 MDC.put(ds_key, key.toString()); } public static void setShardContext(ShardContext context) { SHARD_CONTEXT_HOLDER.set(context); MDC.put(shard_id, context.getShardId()); MDC.put(shard_key, context.getShardKey()); } public static void enableRouteTrace() { ROUTE_TRACE_HOLDER.set(true); MDC.put(route_trace, enabled); } }NamedThreadLocal是自定義類繼承ThreadLocal并重寫toString()方便在Arthas或jstack線程dump中快速識別該ThreadLocal用途——這點在生產環(huán)境排查“某個線程死鎖在數(shù)據(jù)庫連接上”時極其關鍵。2.3 分片上下文注入從Controller到Mapper的全鏈路透傳分片鍵如userId、orderId通常來自HTTP請求參數(shù)或RPC上下文不能靠DAO層自己猜。本項目采用“入口攔截顯式傳遞”模式Web層ShardParam(userId)注解標注Controller方法參數(shù)由ShardArgumentResolver解析并注入ShardContextRPC層Dubbo Filter或gRPC Interceptor從Attachment或Metadata中提取分片信息內部調用Service方法簽名強制要求傳入ShardContext杜絕“隱式上下文”。RestController public class OrderController { GetMapping(/order/{orderId}) public OrderVO getOrder( PathVariable Long orderId, ShardParam(userId) Long userId) { // ← 此注解觸發(fā)ShardContext注入 return orderService.getOrder(orderId, userId); } } Service public class OrderServiceImpl implements OrderService { Override public OrderVO getOrder(Long orderId, Long userId) { // 1. 主動構造ShardContext確保下游能路由 ShardContext context ShardContext.builder() .shardKey(userId) .shardValue(userId) .shardId(ShardAlgorithm.calculateShardId(userId)) // 如 userId % 4 → shard_02 .build(); DataSourceContextHolder.setShardContext(context); // 2. 執(zhí)行實際查詢此時DynamicRoutingDataSource已能獲取shardId return orderMapper.selectById(orderId); } }注意ShardAlgorithm.calculateShardId()必須是純函數(shù)無狀態(tài)、無外部依賴否則在多線程下可能產生不一致分片結果——這是分庫分表最隱蔽的翻車點之一。3. 數(shù)據(jù)源配置與初始化YAML驅動 運行時熱加載支持項目摒棄了XML硬編碼數(shù)據(jù)源的方式采用Spring Boot原生ConfigurationProperties綁定YAML配置同時預留了運行時刷新接口如POST /actuator/datasource/refresh無需重啟即可更新數(shù)據(jù)源連接池參數(shù)。配置結構清晰分層頂層定義邏輯組如master-slave-group中層定義物理實例如ds_master_v2底層定義JDBC屬性。這種結構天然支持灰度發(fā)布場景——你可以先將新庫ds_master_v3加入配置但不啟用待壓測通過后再修改group.default-write-source: ds_master_v3。3.1 application.yml核心配置片段# 多數(shù)據(jù)源基礎配置 spring: datasource: dynamic: primary: master # 默認寫庫 strict: false # 非嚴格模式未匹配到數(shù)據(jù)源時回退到primary datasource: # 主庫寫 master: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://db-master:3306/order_db_v2?useSSLfalseserverTimezoneAsia/Shanghai username: app_rw password: ${DB_MASTER_PWD} hikari: maximum-pool-size: 20 minimum-idle: 5 # 從庫集群讀 slave-01: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://db-slave-01:3306/order_db_v2?useSSLfalseserverTimezoneAsia/Shanghai username: app_ro password: ${DB_SLAVE_PWD} hikari: maximum-pool-size: 15 slave-02: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://db-slave-02:3306/order_db_v2?useSSLfalseserverTimezoneAsia/Shanghai username: app_ro password: ${DB_SLAVE_PWD} hikari: maximum-pool-size: 15 # 分片庫歷史訂單 shard-01: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://db-shard-01:3306/order_history_shard_01?useSSLfalseserverTimezoneAsia/Shanghai username: app_hist password: ${DB_HIST_PWD} shard-02: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://db-shard-02:3306/order_history_shard_02?useSSLfalseserverTimezoneAsia/Shanghai username: app_hist password: ${DB_HIST_PWD}3.2 動態(tài)數(shù)據(jù)源工廠支持運行時新增/刪除數(shù)據(jù)源DynamicDataSourceFactory負責將YAML配置轉化為MapObject, DataSource并注冊到DynamicRoutingDataSource中。關鍵點在于使用ConcurrentHashMap存儲targetDataSources保證put/remove線程安全每次refresh時先關閉舊數(shù)據(jù)源調用HikariDataSource.close()再注入新實例提供getDataSource(String key)方法供其他組件如Druid監(jiān)控按需獲取特定數(shù)據(jù)源。Component public class DynamicDataSourceFactory { private final MapObject, DataSource targetDataSources new ConcurrentHashMap(); PostConstruct public void init() { loadFromConfig(); // 從YAML加載初始數(shù)據(jù)源 } public void refresh(MapString, DataSourceProperties newConfigs) { // 1. 關閉所有舊數(shù)據(jù)源 targetDataSources.values().forEach(this::closeDataSource); targetDataSources.clear(); // 2. 創(chuàng)建新數(shù)據(jù)源并注入 newConfigs.forEach((key, props) - { HikariDataSource ds createHikariDataSource(props); targetDataSources.put(key, ds); }); // 3. 通知DynamicRoutingDataSource更新 dynamicRoutingDataSource.afterPropertiesSet(); } private void closeDataSource(DataSource ds) { if (ds instanceof HikariDataSource) { ((HikariDataSource) ds).close(); } } }注意dynamicRoutingDataSource.afterPropertiesSet()必須顯式調用否則Spring不會重新初始化resolvedDataSources緩存——這是熱加載失敗最常見的原因。3.3 分片策略配置YAML定義規(guī)則Java實現(xiàn)算法分片邏輯不寫死在代碼里而是通過YAML聲明規(guī)則再由Java類按需加載。例如shard: rules: - table: order_info key: user_id algorithm: mod4 sources: [shard-01, shard-02, shard-03, shard-04] - table: order_detail key: order_id algorithm: hash16 sources: [shard-01, shard-02, shard-03, shard-04]對應Java端ShardRuleLoader解析YAML后生成ShardRule對象存入內存并由ShardAlgorithmFactory根據(jù)algorithm字段返回具體實現(xiàn)public interface ShardAlgorithm { String calculateShardId(Object shardValue); } Component public class Mod4ShardAlgorithm implements ShardAlgorithm { Override public String calculateShardId(Object shardValue) { if (!(shardValue instanceof Number)) { throw new IllegalArgumentException(Mod4 requires numeric shard value); } long value ((Number) shardValue).longValue(); int shardIndex (int) (Math.abs(value) % 4); // 避免負數(shù)取模問題 return shard- String.format(%02d, shardIndex 1); // shard-01 ~ shard-04 } }這種解耦讓DBA可獨立修改分片規(guī)則改YAML而開發(fā)只需維護算法實現(xiàn)雙方無需協(xié)同發(fā)布。4. 避坑指南5個真實踩過的坑省下你三天排查時間分庫分表不是配置完就能跑通的銀彈而是處處埋雷的精細活。以下是我在某高校實驗室模擬項目X中連續(xù)兩周壓測時踩出的5個典型問題每一條都附帶復現(xiàn)條件、根因分析和可立即驗證的修復方案。4.1 現(xiàn)象事務內跨庫操作不報錯但部分SQL實際執(zhí)行在錯誤庫上原因Transactional默認傳播行為是REQUIRED當方法A調用方法B時若B未聲明事務其數(shù)據(jù)源路由會脫離A的事務上下文導致B的SQL走默認庫而非事務綁定庫。解決在Transactional方法內所有子調用必須顯式聲明Transactional(propagation Propagation.REQUIRED)或統(tǒng)一使用TransactionTemplate手動控制。更徹底的方案是在DataSourceInterceptor中檢測當前是否在事務中若在則強制將forcedKey設為事務起始時的key。4.2 現(xiàn)象MyBatis二級緩存命中但返回的數(shù)據(jù)卻是舊庫里的臟數(shù)據(jù)原因MyBatis的CachingExecutor在查詢前會先查緩存而緩存key未包含數(shù)據(jù)源標識如ds_key導致從shard-01查到的數(shù)據(jù)被緩存后續(xù)請求即使路由到shard-02也會命中該緩存。解決自定義CacheKey在org.apache.ibatis.cache.CacheKey.update()中加入DataSourceContextHolder.getForcedKey()的哈希值?；蛘摺扑]的做法——禁用跨庫場景的二級緩存在Mapper XML中添加cache evictionFIFO flushInterval60000 size1000 readOnlytrue blockingfalse/并設置useCachefalse。4.3 現(xiàn)象Druid監(jiān)控頁面顯示連接池活躍數(shù)為0但應用日志瘋狂打印“getConnection timeout”原因DynamicRoutingDataSource的determineCurrentLookupKey()方法拋出異常如NullPointerException導致Spring fallback到defaultTargetDataSource而該項目未配置defaultTargetDataSource最終返回nullDruid拿到null后靜默失敗。解決在DynamicRoutingDataSource構造時強制設置setDefaultTargetDataSource(defaultDs)并在determineCurrentLookupKey()最外層加try-catch捕獲所有異常并返回默認key同時記錄ERROR日志“Failed to determine data source key, fallback to default”。4.4 現(xiàn)象單元測試中Test方法能正確路由但集成測試SpringBootTest總是走默認庫原因Spring Boot Test默認使用Mockito代理而DataSourceContextHolder的ThreadLocal在線程切換如Async、CompletableFuture時未做透傳導致異步線程丟失上下文。解決在測試配置中注入TaskExecutorBean并重寫execute()方法在提交任務前拷貝ThreadLocalBean public TaskExecutor taskExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(5); executor.setBeanName(testTaskExecutor); executor.setTaskDecorator(runnable - () - { // 拷貝主線程的DataSource上下文 DataSourceKey key DataSourceContextHolder.getForcedKey(); if (key ! null) { DataSourceContextHolder.setForcedKey(key); } try { runnable.run(); } finally { DataSourceContextHolder.reset(); } }); return executor; }4.5 現(xiàn)象分庫后SELECT COUNT(*) FROM order_info返回結果比單庫少一半原因該SQL未帶WHERE條件ShardAlgorithm無法提取分片鍵路由引擎按默認策略如READ隨機選一個庫執(zhí)行而非廣播到所有分片庫。解決對這類全量聚合SQL必須顯式使用TargetDataSource(broadcast)注解并在BroadcastRouter中實現(xiàn)遍歷所有匹配分片庫分別執(zhí)行SQL再合并結果集。注意COUNT(*)需用SUM()聚合GROUP BY需用UNION ALL去重。5. 運行與驗證從啟動到壓測五步確認路由完全受控光跑通不算成功必須驗證每條SQL都落在預期庫上。本項目提供了一套開箱即用的驗證流水線不依賴外部工具全部基于Spring Boot Actuator和自研Endpoint實現(xiàn)。5.1 啟動檢查確認數(shù)據(jù)源已正確加載啟動應用后訪問GET /actuator/datasource/info返回應包含所有配置的數(shù)據(jù)源及其狀態(tài){ status: UP, details: { master: {status:UP,active:0,idle:5}, slave-01: {status:UP,active:0,idle:3}, shard-01: {status:UP,active:0,idle:2}, shard-02: {status:UP,active:0,idle:2} } }若某個數(shù)據(jù)源狀態(tài)為DOWN檢查日志中是否有HikariPool-1 - Failed to validate connection常見原因是密碼錯誤或網(wǎng)絡不通。5.2 路由追蹤開啟MDC日志實時觀察key生成過程在logback-spring.xml中配置pattern確保輸出%X{ds_key}和%X{shard_id}appender nameCONSOLE classch.qos.logback.core.ConsoleAppender encoder pattern%d{HH:mm:ss.SSS} [%thread] %-5level [%X{ds_key}|%X{shard_id}] %logger{36} - %msg%n/pattern /encoder /appender發(fā)起一次請求日志應類似14:22:05.123 [http-nio-8080-exec-1] DEBUG [WRITE:shard_03:ds_master_v2|shard_03] c.e.o.s.OrderServiceImpl - getOrder called with orderId1001, userId12345 14:22:05.125 [http-nio-8080-exec-1] DEBUG [WRITE:shard_03:ds_master_v2|shard_03] c.e.o.m.OrderMapper.selectById - Preparing: SELECT * FROM order_info WHERE id ?若ds_key為空或與預期不符說明DataSourceContextHolder.setForcedKey()未被調用。5.3 SQL攔截驗證確認MyBatis執(zhí)行的確實是目標庫啟用MyBatis日志logging.level.org.apache.ibatisDEBUG觀察JDBC Connection日志Creating a new SqlSession SqlSession [org.apache.ibatis.session.defaults.DefaultSqlSession7a8b9c0d] was not registered for synchronization because synchronization is not active JDBC Connection [HikariProxyConnection123456789 wrapping com.mysql.cj.jdbc.ConnectionImpl987654321] will not be managed by Spring Preparing: SELECT * FROM order_info WHERE id ?關鍵看wrapping com.mysql.cj.jdbc.ConnectionImplxxxxx后的hashcode對比/actuator/datasource/pools返回的各數(shù)據(jù)源連接池中活躍連接的hashcode——必須一致才證明路由正確。5.4 壓測驗證用JMeter模擬混合流量觀測分片傾斜度編寫JMeter腳本按比例發(fā)送請求70%請求userId在1~100000區(qū)間應均勻分布到4個shard20%請求userId固定為12345應100%落到shard_0310%請求無userId參數(shù)應走默認master庫。壓測10分鐘后執(zhí)行-- 查看各分片庫的order_info表行數(shù) SELECT COUNT(*) FROM order_info; -- 在shard-01庫執(zhí)行 SELECT COUNT(*) FROM order_info; -- 在shard-02庫執(zhí)行 ...理想結果shard-01 ~ shard-04行數(shù)比值接近70%:70%:70%:70%而非出現(xiàn)shard-01: 10w, shard-02: 500的嚴重傾斜。5.5 故障注入測試模擬單庫宕機驗證降級能力手動停掉shard-02數(shù)據(jù)庫容器然后發(fā)送原本應路由到shard-02的請求如userId20001。預期行為若配置spring.datasource.dynamic.strictfalse應自動fallback到primary庫master并記錄WARN日志“Shard shard-02 unavailable, fallback to primary”若配置stricttrue應拋出DataSourceUnavailableException由上層業(yè)務捕獲并返回友好提示。此測試驗證了系統(tǒng)在部分分片不可用時的容錯能力而非直接雪崩。6. 二次開發(fā)與擴展如何安全地接入新業(yè)務、新分片規(guī)則、新數(shù)據(jù)源類型這個項目的設計初衷就是“可演進”而不是一次性交付。我把它用在模擬項目X的三個迭代周期中每次新增需求都只改3個類以內從未動過核心路由引擎。以下是我沉淀下來的四條改造鐵律以及對應的具體操作模板。6.1 接入新業(yè)務表三步完成分片配置假設要為新表user_behavior_log添加分庫分表分片鍵為user_id按mod8分到8個歷史庫Step 1擴展YAML配置在application-prod.yml中追加shard: rules: - table: user_behavior_log key: user_id algorithm: mod8 sources: [shard-log-01, shard-log-02, ..., shard-log-08] spring: datasource: dynamic: datasource: shard-log-01: url: jdbc:mysql://db-log-01:3306/log_db_01?... # ... 共8個數(shù)據(jù)源定義Step 2實現(xiàn)新分片算法Component public class Mod8ShardAlgorithm implements ShardAlgorithm { Override public String calculateShardId(Object shardValue) { long value Math.abs(((Number) shardValue).longValue()); int index (int) (value % 8); return shard-log- String.format(%02d, index 1); } }Step 3在Mapper接口上聲明分片意圖Mapper public interface UserBehaviorLogMapper { Insert(INSERT INTO user_behavior_log (...) VALUES (...)) TargetDataSource(shard-log) // ← 告訴路由引擎此Mapper只走shard-log系列庫 void insert(UserBehaviorLog record); }注意TargetDataSource(shard-log)中的值必須與YAML中sources列表的前綴一致路由引擎會自動匹配shard-log-01等具體實例。6.2 支持新數(shù)據(jù)源類型無縫接入PostgreSQL分片庫項目當前只支持MySQL但某模塊需對接PostgreSQL歷史庫。無需修改DynamicRoutingDataSource只需新增PostgreSqlDataSourceFactory繼承AbstractDataSourceFactory重寫createDataSource()方法在DynamicDataSourceFactory.refresh()中根據(jù)driver-class-name自動選擇工廠類PostgreSQL分片算法與MySQL完全復用Mod8ShardAlgorithm不依賴數(shù)據(jù)庫特性。public class PostgreSqlDataSourceFactory extends AbstractDataSourceFactory { Override protected DataSource createDataSource(DataSourceProperties props) { HikariConfig config new HikariConfig(); config.setJdbcUrl(props.getUrl()); config.setUsername(props.getUsername()); config.setPassword(props.getPassword()); config.setDriverClassName(org.postgresql.Driver); // PostgreSQL特有參數(shù) config.addDataSourceProperty(reWriteBatchedInserts, true); return new HikariDataSource(config); } }6.3 審計增強記錄每次路由決策的完整證據(jù)鏈生產環(huán)境需要審計“某次訂單查詢?yōu)楹巫吡藄hard-03”項目預留了RouteTrace擴展點。啟用方式// 在Controller中 GetMapping(/order/{id}) public OrderVO getOrder(PathVariable Long id) { DataSourceContextHolder.enableRouteTrace(); // ← 開啟追蹤 return orderService.getOrder(id); }啟用后日志自動追加route_path字段[ds_keyREAD:shard_03:slave-01|shard_idshard_03|route_pathANNOTATION→CONTEXT→DEFAULT]其中ANNOTATION→CONTEXT→DEFAULT表示先檢查了TargetDataSource注解未找到再嘗試從參數(shù)提取shardContext成功最后未觸發(fā)默認策略。6.4 灰度發(fā)布支持按用戶ID范圍動態(tài)切流上線新分片庫shard-05時希望先讓userId在1000000~1000010之間的用戶走新庫其余走老庫。只需擴展ShardAlgorithmComponent public class GrayShardAlgorithm implements ShardAlgorithm { Override public String calculateShardId(Object shardValue) { long userId ((Number) shardValue).longValue(); if (userId 1_000_000 userId 1_000_010) { return shard-05; // 灰度庫 } // 兜底走原有mod4算法 return new Mod4ShardAlgorithm().calculateShardId(shardValue); } }然后在YAML中將user_id表的algorithm改為gray即可?；叶冉Y束后刪掉這段if邏輯全程無需改SQL、不發(fā)版。從那以后我每次接入新業(yè)務表都強制走一遍這四步模板配YAML → 寫算法 → 打注解 → 壓測驗證。哪怕凌晨三點上線只要日志里看到[ds_keyWRITE:shard_05:ds_master_v3]心里就踏實。希望幫到你。本文還有配套的精品資源點擊獲取