1. 为什么要在Java项目里手写分库分表配置分库分表这件事很多团队第一次接触都是被数据量逼出来的。单表几千万行索引再优化查询也开始肉眼可见地变慢写入更是频繁锁等待。这个时候你面前通常有两条路一条是上中间件代理层另一条是在应用层直接做数据源路由。前者对业务代码侵入小但多了一层网络跳转和运维成本后者把逻辑收进Java代码里灵活、可控、排查方便尤其适合已经用Spring Boot体系的中小团队。ShardingSphere的Java配置方式走的就是第二条路。它本质上是把分片规则、数据源、读写分离策略这些东西通过Java代码或者配置文件告诉框架让它在执行SQL之前帮你改写成对应的真实表名和库名再把结果合并回来。你写select * from order它可能实际执行的是select * from order_2甚至跨两个库去查再归并。对上层业务来说SQL基本不用大改这是它最舒服的地方。这篇文章适合谁看如果你正在做订单、日志、流水这类天然适合水平拆分的表或者你已经被单库连接数打满、磁盘IO顶到天花板那这套配置思路可以直接参考。如果你只是刚听说分库分表想先搞清楚Java配置到底长什么样、有哪些坑那也能从下面的拆解里拿到一份能跑起来的骨架。我会按“整体设计—核心细节—实操落地—问题排查”的顺序讲尽量把每个参数为什么这么设说清楚。2. 整体方案设计与选型思路拆解2.1 分片键和分片算法的选择逻辑分库分表第一步不是写代码是想清楚拿哪个字段当分片键。这个字段决定了数据怎么散、查询怎么走、扩容怎么扩。以订单表为例常见的候选有user_id、order_id、create_time。选user_id的好处是同一个用户的订单都落在同一个库同一张表按用户维度查询天然单库单表缺点是运营侧按订单号查就得全路由。选order_id则相反订单号查询精准但用户维度查询会散。我的经验是优先按业务最核心的查询维度来分。如果C端用户查自己的订单是主流量那就用user_id如果后台按订单号处理是主流量那就用order_id。实在两个维度都重可以考虑基因法把用户ID的后几位编进订单号让两个维度都能定位但这会增加生成逻辑的复杂度不是所有团队都值得上。分片算法上取模是最简单直接的user_id % 4落到4个库。它的问题是扩容麻烦从4库扩到8库几乎所有数据都要迁移。一致性哈希能缓解扩容迁移量但实现和运维更重。还有一种范围分片按ID区间或者时间区间切扩容方便但容易产生热点比如按时间分新数据全压在一个分片上。中小团队我一般建议先用取模把业务跑通等真到了要扩容那天再评估迁移方案别一上来就过度设计。2.2 Java配置和YAML配置怎么选ShardingSphere支持YAML和Java两种配置方式。YAML的好处是规则集中、改配置不用重新编译适合运维和开发分离的团队。Java配置的好处是灵活你可以根据环境变量、启动参数动态拼装规则也能把配置和Spring的Bean体系深度结合做条件化装配。我选Java配置的场景通常是这几种分片规则需要根据租户动态变化数据源信息来自配置中心而不是本地文件需要在启动时做规则校验和日志打印。反过来如果规则很稳定、就是几张表固定分几个库那YAML更省事改完重启即可不用碰代码。这里有个容易忽略的点Java配置写出来的规则对象本质上是ShardingSphere的ShardingRuleConfiguration、DataSourceConfiguration这些类。它们不是Spring的原生Bean需要你自己包一层Bean方法交给容器管理。很多人第一次配的时候直接把规则new出来就用了结果数据源没初始化启动就报空指针。正确做法是把数据源、规则、最终的DataSource都作为Bean暴露出去。2.3 数据源组织方式独立数据源还是统一封装分库之后你有多个物理数据源。ShardingSphere的做法是让你把这些物理数据源注册进一个Mapkey是逻辑名value是真实的DataSource对象然后它内部再包一层ShardingDataSource对外暴露。业务代码注入的是这个ShardingDataSource不是某个具体的物理数据源。这里要特别注意不要让业务代码直接依赖物理数据源。一旦有人绕过ShardingSphere直接拿某个库的连接去查分片逻辑就失效了数据可能查不全。我见过有团队为了图快在某个报表接口里直接注入了物理数据源结果上线后数据对不上排查了半天才发现是绕过了路由。所以数据源的封装边界一定要在代码规范里写死。3. 核心配置细节与实操要点3.1 数据源配置的写法与参数含义先看数据源部分。每个物理库对应一个DataSource通常用连接池比如HikariCP。关键参数有jdbcUrl、username、password、maximumPoolSize、connectionTimeout。分库之后连接池总数是各库之和比如4个库每个20连接总共80个连接这个数字要跟数据库的max_connections对齐别把库打满。Bean public DataSource shardingDataSource() throws SQLException { MapString, DataSource dataSourceMap new HashMap(); dataSourceMap.put(ds0, createDataSource(jdbc:mysql://host0:3306/db0)); dataSourceMap.put(ds1, createDataSource(jdbc:mysql://host1:3306/db1)); // 分片规则配置 ShardingRuleConfiguration ruleConfig new ShardingRuleConfiguration(); // ... 规则细节见下文 return ShardingDataSourceFactory.createDataSource(dataSourceMap, ruleConfig, new Properties()); }createDataSource里就是标准的Hikari配置。这里有个细节jdbcUrl里要带上serverTimezone和useSSLfalse这类参数否则启动时可能因为时区或SSL握手报错。另外每个库的库名要真实存在ShardingSphere不会帮你建库建表表结构得提前在所有分片上都建好。3.2 分片规则配置表规则与分片算法分片规则的核心是ShardingTableRuleConfiguration它要指定逻辑表名、实际数据节点、分库策略、分表策略。实际数据节点用ds${0..1}.order_${0..1}这种表达式表示两个库各两张表一共4个分片。ShardingTableRuleConfiguration orderTableRule new ShardingTableRuleConfiguration(order, ds${0..1}.order_${0..1}); orderTableRule.setDatabaseShardingStrategy( new StandardShardingStrategyConfiguration(user_id, dbShardingAlgorithm)); orderTableRule.setTableShardingStrategy( new StandardShardingStrategyConfiguration(user_id, tableShardingAlgorithm)); ruleConfig.getTables().add(orderTableRule);分片算法需要自己实现PreciseShardingAlgorithm和RangeShardingAlgorithm。精确分片用于和in范围分片用于between和。很多人只实现了精确分片结果范围查询直接报错这是最常见的坑之一。public class DbShardingAlgorithm implements PreciseShardingAlgorithmLong { Override public String doSharding(CollectionString availableTargetNames, PreciseShardingValueLong shardingValue) { long value shardingValue.getValue(); String target ds (value % 2); if (availableTargetNames.contains(target)) { return target; } throw new IllegalArgumentException(no target for value); } }算法里一定要做availableTargetNames.contains校验否则配置写错时错误信息会非常隐晦。范围分片则要返回所有可能命中的目标集合不能只返回一个。3.3 绑定表与广播表的配置取舍绑定表解决的是关联查询的笛卡尔积问题。如果order和order_item都按user_id分片且分片规则完全一致那它们就是绑定表关系。配置了绑定表之后order join order_item只会在这两个表相同的分片上执行不会4个分片两两组合成16次查询。ruleConfig.getBindingTableGroups().add(order, order_item);广播表则是那些数据量小、每个库都要有一份全量数据的表比如字典表、配置表。配置成广播表后写操作会同步到所有库读操作走任意一个库。要注意广播表不适合频繁写入的大表否则同步开销会拖垮性能。提示绑定表要求分片键和分片算法完全一致如果两张表一个用user_id一个用order_id强行配绑定表会导致数据错乱这个坑很深。4. 完整实操流程与关键环节实现4.1 环境准备与依赖引入先确认版本。ShardingSphere 5.x和4.x的API差异很大5.x把很多配置类挪到了org.apache.shardingsphere包下4.x还在io.shardingsphere。网上很多老教程是4.x的直接抄会编译不过。我建议新项目直接用5.x稳定版。dependency groupIdorg.apache.shardingsphere/groupId artifactIdshardingsphere-jdbc-core-spring-boot-starter/artifactId version5.3.2/version /dependency如果不用starter就引shardingsphere-jdbc-core然后自己配Bean。用starter的话它会自动装配一些东西但Java配置模式下我一般还是手动配避免自动装配和手动规则冲突。4.2 建库建表与初始化数据分片表要在每个物理库上都建好表名要跟规则里的实际节点对应。比如ds0和ds1两个库每个库建order_0和order_1两张表。建表语句除了表名不同结构必须完全一致否则路由到不同分片时字段对不上会报错。CREATE TABLE order_0 ( order_id BIGINT PRIMARY KEY, user_id BIGINT NOT NULL, amount DECIMAL(10,2), create_time DATETIME, KEY idx_user (user_id) ) ENGINEInnoDB;索引也要在每个分片上建别只在一个库建。我见过有人只在ds0建了索引结果查询路由到ds1时全表扫描性能直接崩。初始化数据时可以用循环插入测试数据验证路由是否正确。4.3 配置类完整实现与启动验证把数据源、规则、算法串起来形成一个完整的配置类。启动后第一件事是验证路由插一条user_id1的数据看它落到哪个库哪张表。可以用日志或者直接连库查。Configuration public class ShardingConfig { Bean public DataSource dataSource() throws SQLException { MapString, DataSource map new HashMap(); map.put(ds0, buildDs(jdbc:mysql://host0:3306/db0)); map.put(ds1, buildDs(jdbc:mysql://host1:3306/db1)); ShardingRuleConfiguration rule new ShardingRuleConfiguration(); ShardingTableRuleConfiguration orderRule new ShardingTableRuleConfiguration(order, ds${0..1}.order_${0..1}); orderRule.setDatabaseShardingStrategy( new StandardShardingStrategyConfiguration(user_id, new DbShardingAlgorithm())); orderRule.setTableShardingStrategy( new StandardShardingStrategyConfiguration(user_id, new TableShardingAlgorithm())); rule.getTables().add(orderRule); rule.getBindingTableGroups().add(order, order_item); Properties props new Properties(); props.setProperty(sql-show, true); return ShardingDataSourceFactory.createDataSource(map, rule, props); } }sql-show设为true会把改写后的SQL打到日志里调试阶段非常有用能看到它到底把order改成了order_1还是order_0。上线后建议关掉否则日志量很大。4.4 读写分离与分片的组合配置如果每个库还有主从可以在分片基础上叠加读写分离。做法是每个逻辑库对应一个读写分离数据源再把这些数据源注册进分片的数据源Map。顺序是先配主从数据源再配分片规则最后用分片数据源包起来。// 每个库的主从 ReadwriteSplittingDataSourceRuleConfiguration rw new ReadwriteSplittingDataSourceRuleConfiguration(ds0, master0, Arrays.asList(slave0), null);读写分离的负载均衡算法默认是轮询也可以配随机。要注意主从延迟问题写后立即读可能读到旧数据对一致性要求高的场景要强制走主库ShardingSphere支持通过Hint强制路由。5. 常见问题与排查技巧实录5.1 路由错误与数据查不全最常见的现象是明明插了数据按某个条件查却查不到。原因通常是分片键没传或者传了但算法算错。比如查询条件里没有user_idShardingSphere无法定位分片就会全路由如果算法实现有bug可能漏掉某个分片。排查方法打开sql-show看实际执行的SQL列表。如果只执行了一个分片的SQL但数据在另一个分片那就是算法算错了。检查算法里的取模逻辑注意负数取模在Java里结果是负数-1 % 2 -1会导致目标名拼成ds-1直接报错。所以算法里要先取绝对值。5.2 分布式主键冲突分库分表后自增主键不再全局唯一两个库可能生成相同的ID。解决办法是用分布式主键比如雪花算法。ShardingSphere内置了SNOWFLAKE主键生成器配置在表规则里即可。orderRule.setKeyGenerateStrategy( new KeyGenerateStrategyConfiguration(order_id, snowflake)); ruleConfig.getKeyGenerators().put(snowflake, new SnowflakeKeyGenerateAlgorithm());雪花算法依赖机器ID集群部署时要保证每个实例的机器ID不同否则还是会冲突。可以用IP末位或者配置中心分配。5.3 分页查询性能问题分页是分库分表的老大难。limit 100000, 10这种深分页ShardingSphere会把limit改写成limit 0, 100010在每个分片执行然后内存归并数据量大时内存直接爆。优化思路是限制最大翻页数或者用游标方式带上上一页的最大ID作为条件。问题现象可能原因排查方向启动报空指针数据源未初始化检查Bean装配顺序查询结果重复归并逻辑或绑定表配置错检查绑定表分片键是否一致写入慢跨分片事务或广播表同步检查是否命中单分片范围查询报错未实现Range算法补全RangeShardingAlgorithm注意跨分片的join和事务性能很差能避免就避免。设计阶段就要尽量让关联数据落在同一分片。5.4 实操避坑心得踩过几次坑之后我总结了几条第一分片算法一定要写单元测试把边界值、负数、null都覆盖到第二上线前用真实数据量做压测别拿几百条数据测完就上第三sql-show在预发环境常开上线关掉第四分片键一旦定了后期改代价极大前期多花时间论证。还有一点ShardingSphere的版本升级要谨慎5.x小版本之间API也有变动升级前先看release note。这个内容后续还可以这样扩展把分片规则做成配置中心动态下发支持不停机调整分片数或者结合影子库做全链路压测。不过那是另一个话题了先把基础的分库分表跑稳比什么都重要。