简介本资源是一套基于Spring Boot的多数据源与分库分表实战项目面向Java后端开发者及数据库架构进阶学习者聚焦高并发场景下的数据层扩展难题。项目整合Dynamic-Datasource实现多数据源动态路由采用Sharding-JDBC完成水平分表结合Druid连接池进行性能监控与管理并通过MyBatis-Plus简化CRUD、Lombok减少模板代码辅以JUnit单元测试保障质量。压缩包共162个文件含115个XML映射文件定义SQL逻辑、14个Java业务类如OrderController、UserTestServiceImpl等、6个YML配置文件多源与分片规则、以及日志、测试脚本等辅助文件整体仅164KB轻量易读。已有623人学习下载提供开箱即用的完整工程结构、典型分表场景如订单/用户表拆分的可运行示例、清晰的配置分层与测试验证链路是理解分库分表落地细节与Spring Boot数据层集成方案的优质参考。1. 多数据源 数据库分库分表不是加个配置就能跑通的“高可用幻觉”而是业务增长到200万日活、单库QPS破3000后你不得不亲手拆掉的那堵墙很多团队在技术评审会上听到“多数据源分库分表”时第一反应是——“哦上ShardingSphere或者MyCat就行”。结果上线三天订单查不到、库存扣重了、跨库JOIN返回空、事务回滚像开盲盒。这不是中间件不靠谱而是把“多数据源”和“分库分表”当成两个独立开关去按一个管连哪几个库一个管数据往哪分。但真实场景里它们是咬合传动的齿轮——数据源路由策略决定分片键怎么选分片规则反向约束数据源发现机制而事务一致性则要求两者必须在同一套生命周期里被编排。本文讲的不是“如何配置ShardingSphere的yaml”而是从零开始用MySQL 8.0 Spring Boot 3.2 ShardingSphere-JDBC 5.3.2把一个电商订单中心从单库单表平滑演进到4主库×3分片共12物理库覆盖读写分离、水平分片、分布式ID、跨库事务补偿、以及最关键的——如何让开发同学写SQL时几乎感觉不到底层已分裂。适合正在经历QPS陡增、慢查询报警频发、DBA天天催扩容、但又不敢贸然切分核心业务的中型技术团队。2. 为什么必须先定义“数据源拓扑”再设计“分片逻辑”避免90%的翻车始于第一步误判2.1 数据源拓扑不是罗列URL而是刻画“谁服务谁、谁依赖谁、谁容灾谁”多数据源 ≠ 简单堆数据库连接。它是一张有向拓扑图角色维度主库写、从库读、归档库历史查询、影子库压测地域维度华东集群主、华北集群从、海外节点只读缓存业务维度订单库强一致性、用户库最终一致、日志库异步写入。ShardingSphere-JDBC 的spring.shardingsphere.datasource.names只是起点。真正关键的是spring.shardingsphere.rules[0].data-source-rules—— 它定义每个逻辑数据源如ds_order背后挂载的物理数据源集合及权重。例如spring: shardingsphere: rules: - !DATA_SOURCE_RULE dataSources: ds_order: # 逻辑数据源名 write-data-source-name: ds_order_master_0 # 写库标识 read-data-source-names: # 读库列表支持权重 - ds_order_slave_0: 3 - ds_order_slave_1: 1 load-balancer-name: ROUND_ROBIN # 负载均衡策略提示write-data-source-name和read-data-source-names必须指向已在datasource下声明的物理数据源名如ds_order_master_0且不能混用同一物理库既当写又当读——否则主从延迟导致脏读。我见过最惨的一次翻车开发把ds_order_slave_0同时配在write-data-source-name和read-data-source-names里结果促销秒杀时大量读到未提交的“幽灵订单”。2.2 分片逻辑前置用“业务实体生命周期”代替“技术字段哈希”分库分表常被简化为“对user_id取模”。但订单的生命周期远比用户长创建 → 支付 → 发货 → 确认收货 → 售后 → 归档。不同阶段访问模式差异巨大创建/支付高频写强一致性要求发货/确认中频读写需关联物流表售后/归档低频读可接受分钟级延迟。因此分片键sharding key必须是贯穿全生命周期的稳定标识且能天然隔离热点。我们放弃order_idUUID无序范围查询失效也放弃user_id头部用户订单集中易成热点最终选定order_no业务生成的16位数字编码前4位年月后12位序列号全局唯一且有序。分片策略如下分片维度策略类型表达式说明库分片database strategy标准分片ds_${order_no % 4}order_no末位模4均匀打散到4个主库表分片table strategy标准分片t_order_${order_no % 3}同一库内再模3每库3张物理表注意order_no % 4和order_no % 3是独立计算不是嵌套。ShardingSphere 会先算出库名ds_0~ds_3再在该库内算出表名t_order_0~t_order_2。这种解耦设计让扩容更灵活——加库只需改库分片算法加表只需改表分片算法。2.3 为什么必须禁用JDBC默认的autoCommit分布式事务的起点在这里Spring Boot 默认开启autoCommittrue。但在分库分表场景下一次Service方法调用可能涉及多个物理库的写操作如扣库存写ds_inventory生成订单写ds_order记录日志写ds_log。若保持autoCommit每个SQL都立即提交根本无法保证ACID。必须显式关闭Configuration public class DataSourceConfig { Bean Primary public DataSource dataSource() { // ShardingSphereDataSourceFactory.createDataSource(...) // 此处省略构建逻辑 return shardingDataSource; } Bean Primary public PlatformTransactionManager transactionManager(DataSource dataSource) { DataSourceTransactionManager manager new DataSourceTransactionManager(); manager.setDataSource(dataSource); // 关键强制禁用autoCommit交由事务管理器控制 manager.setAutodetectDataSource(false); return manager; } }血泪经验某次上线后发现“订单创建成功但库存没扣”排查发现开发在DAO层手动调用了connection.setAutoCommit(true)绕过了Spring事务——所有直接获取Connection的操作在分库分表环境下都是定时炸弹。3. 分片键与SQL写法的隐性契约90%的“分片路由失败”源于开发写的SQL违反了底层约定3.1 必须带分片键WHERE条件否则ShardingSphere拒绝路由直接报错ShardingSphere-JDBC 的分片路由是静态解析SQL而非运行时探查。它只识别WHERE子句中明确等于、IN、BETWEEN 的分片键条件。以下SQL全部无法路由会抛SQLException: Cannot route any database or table for t_order-- ❌ 错误1无分片键条件全表扫描分库分表禁止 SELECT * FROM t_order WHERE status paid; -- ❌ 错误2分片键参与函数计算无法解析 SELECT * FROM t_order WHERE YEAR(create_time) 2024; -- ❌ 错误3分片键用OR连接ShardingSphere 5.x暂不支持OR分片路由 SELECT * FROM t_order WHERE order_no 12345 OR user_id 67890;正确写法必须是-- ✅ 正确精确匹配分片键 SELECT * FROM t_order WHERE order_no 12345; -- ✅ 正确IN批量查询分片键值必须落在同一库表 SELECT * FROM t_order WHERE order_no IN (12345, 67890, 24680); -- ✅ 正确BETWEEN范围查询需确保范围不跨分片 SELECT * FROM t_order WHERE order_no BETWEEN 10000 AND 19999;玄学提醒BETWEEN查询能否命中单一分片取决于你的分片算法。我们用order_no % 4分库那么order_no BETWEEN 10000 AND 19999肯定落在同一库因为10000%4019999%43实际跨4个库。所以范围查询必须配合业务约束——比如约定订单号前4位代表月份查“202405月订单”就写WHERE order_no BETWEEN 2024050000000000 AND 2024059999999999此时2024050000000000 % 4 2024059999999999 % 4必然同库。3.2 JOIN的生死线只允许同库同表JOIN跨库JOIN必须重构为应用层组装ShardingSphere 支持Broadcast Join广播表JOIN和Sharding Join分片表JOIN但前提是JOIN的两张表必须使用相同的分片键和分片算法。例如-- ✅ 允许t_order与t_order_item用相同order_no分片 SELECT o.*, i.* FROM t_order o JOIN t_order_item i ON o.order_no i.order_no WHERE o.order_no 12345;但以下全部禁止-- ❌ 禁止跨库JOINt_order在ds_order库t_user在ds_user库 SELECT o.*, u.name FROM t_order o JOIN t_user u ON o.user_id u.id WHERE o.order_no 12345; -- ❌ 禁止不同分片键JOINt_order用order_not_product用product_id SELECT o.*, p.name FROM t_order o JOIN t_product p ON o.product_id p.id WHERE o.order_no 12345;解决方案只有两种应用层组装先查t_order提取user_id列表再查t_user走单库路由最后内存合并冗余字段在t_order表里冗余user_name字段用MQ或Binlog同步更新——这是我们最终选择牺牲写一致性换取读性能。3.3 ORDER BY LIMIT的陷阱分页深度越大性能越接近全表扫描分库分表下的ORDER BY ... LIMIT是典型“N1”问题。例如-- ❌ 危险查第1000页每库都要返回1000条再内存排序取前10 SELECT * FROM t_order ORDER BY create_time DESC LIMIT 10000, 10;ShardingSphere 会将LIMIT 10000,10拆解为LIMIT 1000010发给每个物理库汇总后取TOP10。4个库 × 10010 40040条数据内存排序CPU飙升。生产环境必须禁用深度分页改用游标分页cursor-based pagination-- ✅ 安全用上一页最大create_time作为游标 SELECT * FROM t_order WHERE create_time 2024-05-20 10:00:00 ORDER BY create_time DESC LIMIT 10;后悔药上线前用sharding-sphere-sql-parser工具离线扫描全量SQL过滤出所有含LIMIT且无WHERE分片键的语句逐条改造。我们曾扫出27处违规分页其中3处已在灰度环境引发OOM。4. 避坑分库分表落地中最常踩的5个深坑现象、原因、解法全写清楚4.1 现象插入数据后SELECT COUNT(*) FROM t_order返回0但单库查有数据原因COUNT(*)是聚合操作ShardingSphere默认将COUNT(*)下推到各物理库执行再汇总结果。但如果某个物理库因网络抖动未响应ShardingSphere会返回错误而非0而某些客户端驱动如旧版MySQL Connector/J会将错误转为0。解决升级MySQL驱动至8.0.33在ShardingSphere配置中显式启用sql-show: true观察日志确认是否所有库都返回了COUNT结果生产环境禁用COUNT(*)改用SELECT COUNT(1) FROM t_order WHERE order_no 0强制带上分片键条件确保路由到具体库。4.2 现象INSERT INTO t_order (...) VALUES (...)报错Duplicate entry xxx for key PRIMARY但查表无此主键原因自增主键AUTO_INCREMENT在分库分表下失效。每个物理库的t_order_0表都有自己的自增起始值插入时可能冲突。解决彻底弃用数据库自增改用分布式ID生成器如Snowflake我们采用shardingsphere-jdbc内置的snowflake类型配置如下spring: shardingsphere: rules: - !SHARDING tables: t_order: actual-data-nodes: ds_${0..3}.t_order_${0..2} key-generate-strategy: column: order_no # 注意这里用业务主键order_no非id key-generator-name: snowflake key-generators: snowflake: type: SNOWFLAKE props: worker-id: 123 # 每个应用实例唯一4.3 现象事务内跨库更新部分库成功、部分库回滚最终数据不一致原因ShardingSphere-JDBC 的LOCAL事务模式本质是尽力而为Best Effort不提供XA强一致。当ds_order提交成功ds_inventory回滚时ShardingSphere只能抛异常无法自动补偿。解决对强一致性场景如扣库存创订单改用XA模式需数据库支持XAMySQL 5.7需开启innodb_support_xaON更推荐方案Saga模式——将扣库存、创订单、发消息拆成独立服务失败时触发逆向操作补库存、删订单、撤消息。我们用Seata框架实现GlobalTransactional注解包裹整个流程。4.4 现象UPDATE t_order SET statusshipped WHERE order_no12345执行后SELECT查不到变更原因ShardingSphere 的读写分离默认走从库但主从同步有延迟。UPDATE写主库后立即SELECT可能从从库读到旧数据。解决开启hint强制读主库HintManager.getInstance().setWriteRouteOnly();更优雅方案基于binlog的缓存穿透保护——更新后立即删除Redis中对应order:12345缓存下次读强制查库此时主从已同步或配置load-balance-algorithm为RANDOM降低从库读取概率。4.5 现象DELETE FROM t_order WHERE order_no IN (12345,67890)删除了1条但预期2条原因IN列表中的分片键值必须全部落在同一物理库否则ShardingSphere会拆成多个SQL下发但DELETE语句不支持跨库事务部分成功部分失败时无回滚。解决严格校验IN列表计算12345 % 4 167890 % 4 2二者不同库禁止执行业务层拆分ListLong orderNos ...; MapInteger, ListLong grouped orderNos.stream().collect(Collectors.groupingBy(no - (int)(no % 4)));再对每组分别执行DELETE。5. 分库分表后的监控与治理没有可观测性分片就是黑匣子5.1 必须接入的3类核心指标用PrometheusGrafana搭起来分库分表后传统单库监控完全失效。我们重点采集以下三类指标全部通过ShardingSphere内置的Metrics模块暴露指标类别Prometheus指标名业务含义告警阈值排查价值路由健康shardingsphere_routing_count_totalSQL路由到物理库/表的次数单库路由数突增300%判断分片算法是否倾斜执行耗时shardingsphere_execution_time_seconds_sum所有物理库SQL执行总耗时P95 500ms定位慢库如某从库延迟高连接池shardingsphere_datasource_active_connections每个物理数据源活跃连接数 最大连接数80%发现连接泄漏或配置过小Grafana看板必须包含分片热度热力图X轴库名ds_0~ds_3Y轴表名t_order_0~t_order_2颜色深浅该库表QPS跨库SQL计数器统计SELECT ... JOIN、UNION ALL等跨库操作频次超阈值立即告警事务成功率趋势shardingsphere_transaction_success_rate低于99.9%即触发根因分析。5.2 每周必做的2项数据治理动作防微杜渐动作1分片键分布校验Python脚本自动化每月初运行脚本验证order_no的分布是否均匀。原理抽样10万条订单统计order_no % 4的分布比例偏差超过±5%即预警。# check_sharding_balance.py import pymysql import numpy as np def check_db_balance(): conn pymysql.connect(hostproxy, port3306, useradmin, passwordpwd) cursor conn.cursor() cursor.execute(SELECT order_no FROM t_order ORDER BY RAND() LIMIT 100000) order_nos [row[0] for row in cursor.fetchall()] buckets [0,0,0,0] for no in order_nos: buckets[no % 4] 1 ratios [b/len(order_nos)*100 for b in buckets] print(fBucket ratios: {ratios}) # 应接近 [25,25,25,25] if max(ratios) - min(ratios) 5: raise Exception(Sharding imbalance detected!) if __name__ __main__: check_db_balance()动作2SQL兼容性扫描Maven插件集成CI在CI流水线中加入shardingsphere-sql-parser插件扫描所有Mapper XML和注解SQL!-- pom.xml -- plugin groupIdorg.apache.shardingsphere/groupId artifactIdshardingsphere-sql-parser-maven-plugin/artifactId version5.3.2/version executions execution goals goalparse/goal /goals configuration sqlFiles sqlFilesrc/main/resources/mapper/*.xml/sqlFile /sqlFiles forbiddenPatterns forbiddenPatternSELECT \* FROM .* WHERE .* NOT IN \(.*\)/forbiddenPattern forbiddenPatternUPDATE .* SET .* WHERE .* OR .*/forbiddenPattern /forbiddenPatterns /configuration /execution /executions /plugin我的习惯每周五下午我会花15分钟看一眼Grafana热力图再跑一遍分片校验脚本。如果连续三周ds_2的t_order_1表QPS高出均值40%我就知道——该给ds_2加从库了。分库分表不是一劳永逸的银弹而是需要持续校准的精密仪器。希望帮到你。本文还有配套的精品资源点击获取