ShardingSphere-JDBC水平分片实战：从原理到配置破解单库瓶颈

接手交易系统维护那阵子，最头疼的就是订单表。一千万行数据摆在那里，单库连接数天天报警，慢查询把夜里的大促压得喘不过气。后来用ShardingSphere-JDBC做了水平分片，才真正把单库压力拆开。ShardingSphere-JDBC是一个以JDBC驱动形式嵌在应用进程内的轻量级数据库中间件，核心能力就是把一条SQL按规则路由到不同的物理库和物理表上执行，业务代码几乎不用动。如果你也在面对单表数据量过大、单库连接数吃紧、写入吞吐上不去的问题，这篇文章应该能帮你理清水平分片怎么落地，以及有哪些坑是文档里不会写的。

1. 为什么要做水平分片：单库瓶颈与业务驱动的拆库逻辑

1.1 单库在什么情况下撑不住

先说一个基础判断：不是所有系统都需要分片。很多团队一听到“千万数据量”就紧张，其实MySQL单表在数据量控制合理、索引字段精简、查询以点查为主的情况下，跑到几百万甚至上千万行都还是能扛的。真正的瓶颈往往不是“数据量”，而是三个东西叠加在一起：单表体积、并发连接数、写入吞吐。

单表体积上来之后，B+树层级变深，热数据在InnoDB缓冲池里的命中率下降，同样的查询要读更多页，响应时间就开始抖。备份和DDL也会变成大问题，一张大表做一次结构变更可能要锁很久。而连接数就更直接了，数据库连接是稀缺资源，连接池被占满之后，新的请求只能排队，表现就是接口RT突然从几十毫秒跳到几百毫秒，甚至直接报获取连接超时。写入吞吐则是单实例写盘能力的上限，一个主库的写入TPS是有天花板的，业务再增长，单库也顶不上去。

我见过的系统大部分不是赢在某个单一指标上，而是三样同时到了临界点。这个时候与其给单库做无底洞式的加配置，不如用水平分片把数据“摊开”。

1.2 水平分片与垂直分片的区别与选型

分片方向和拆法完全不同。垂直分片是按业务模块或字段维度拆，比如把订单基础信息、订单扩展信息拆成两张表，或者把一个库拆成订单库、用户库、商品库；水平分片是按数据行维度拆，同一张表的数据按规则散落到多个库或多张表里，每张表只存一部分行。

在实际选型上，我的习惯是先垂直后水平。系统里往往有些字段访问频率极低、又特别占用存储（比如大文本、JSON），摘出去收益很大。但如果把所有高频写入都集中在一个模块上，垂直分片解决不了热点，就需要水平分片了。

对比项	垂直分片	水平分片
拆分维度	按业务字段/模块拆	按数据行拆
表结构	各分片表结构不同	各分片表结构一致
解决的核心问题	表字段过多、模块间相互影响	单表数据量大、单库写入和连接瓶颈
实现复杂度	相对简单，改SQL/改接口即可	需要路由中间件或自研分片逻辑
后续扩展	适合业务模块拆分	适合数据量持续增长

水平分片又分“分库”“分表”“分库分表”三种粒度。如果单库连接数和写入吞吐是瓶颈，优先分库；如果单表查询性能和大表DDL是瓶颈，优先分表；如果两者都踩中，就分库分表一起做。ShardingSphere-JDBC对这几个粒度都支持，实际-data-nodes配置里把库和表的范围写清楚就行。

2. ShardingSphere-JDBC的核心工作流程：一条SQL是怎么跨库执行的

2.1 路由、改写、执行、归并四步

ShardingSphere-JDBC对一条SQL的处理可以拆成四个阶段：解析与路由、SQL改写、执行、结果归并。很多人把它当成“黑盒”，但从排查问题角度，这四个阶段必须理解清楚。

解析阶段，中间件用Antlr对SQL做语法解析，生成抽象语法树，再提取出逻辑表名、查询列、WHERE条件里的分片键值等关键信息。路由阶段，根据配置的分片算法，把这条SQL匹配到真实的数据节点上。如果WHERE里带了分片键的等值条件，路由到单个节点；如果是范围条件，路由到多个相关节点；如果完全没带分片键，只能走全路由，也就是把所有分片都扫一遍。

SQL改写阶段，把逻辑SQL改写成能在真实物理表上执行的SQL。比如逻辑表t_order会被改写成t_order_0、t_order_1这些具体表名，同时如果SQL里有聚合函数、ORDER BY、LIMIT等涉及归并语义的语句，中间件会自动补充或调整，让各个分片返回的结果能在归并阶段正确合并。

执行阶段，中间件通过底层数据库连接池并发地把改写后的SQL发到各物理节点执行。归并阶段，把多个节点返回的结果集合并。这里表面上是一套流程，实际上每一步都藏着性能细节。比如归并就分好几种：流式归并适合ORDER BY + 非聚合查询，可以边读边归并，内存占用小；内存归并适合GROUP BY + 聚合场景，要把所有分片结果先读到内存再聚合，数据量一大就会比较吃力。

2.2 逻辑表与真实表的映射关系

理解水平分片，先要把“逻辑表”和“真实表”这对概念吃透。配置里写的t_order是逻辑表，它对业务代码是透明的，SQL里永远写t_order。而实际存储是t_order_0、t_order_1等物理表，分散在ds0、ds1等库里。

配置里的actual-data-nodes就是描述这种映射关系的。写ds$->{0..1}.t_order_$->{0..1}的意思是：两个库，每个库两张表，组合成4个数据节点。也可以写成枚举形式，比如ds0.t_order_0, ds0.t_order_1, ds1.t_order_0, ds1.t_order_1，两种写法效果一样，行表达式更简洁。

这个映射关系是路由的“地图”。分片算法决定“去哪”，数据节点决定“有哪些地方可去”。两者都要配置正确，否则会出现路由到不存在的物理表，直接报错。

2.3 分片键和分片算法的识别机制

分片键就是决定数据去哪个节点的字段，配合分片算法一起工作。中间件在解析阶段会从WHERE条件里提取分片键的值，然后交给分片算法计算目标节点。

能不能精准路由，取决于SQL里分片键的写法。等值条件（如order_id = 1001）和IN条件（如order_id IN (1001, 1002)）都能被正常提取。范围条件（如create_time >= '2024-01-01'）需要分片算法支持范围路由，比如按时间分片的INTERVAL算法。最怕的是分片键被函数包裹，比如WHERE DATE(create_time) = '2024-01-01'，解析阶段拿不到原始的分片键值，就只能全路由去扫。

还有一个常见的认知误区：以为配置了分片策略，中间件就会自动优化全路由查询。实际上不会，它只是忠实地按规则执行。所以写出“能命中分片键”的SQL，是使用水平分片的基本功。

3. 从零搭一个订单分库分表示例（Spring Boot + MySQL）

3.1 建库建表与工程依赖

先说准备工作：两个物理库，每个库两张表，表结构完全一致。DDL大致是这样的：

CREATE DATABASE IF NOT EXISTS ds0 DEFAULT CHARACTER SET utf8mb4; CREATE DATABASE IF NOT EXISTS ds1 DEFAULT CHARACTER SET utf8mb4; -- 分别在 ds0、ds1 中执行 CREATE TABLE IF NOT EXISTS t_order_0 ( order_id BIGINT NOT NULL, user_id BIGINT NOT NULL, amount DECIMAL(10, 2) DEFAULT 0, status INT DEFAULT 0, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (order_id) ) ENGINE=InnoDB; CREATE TABLE IF NOT EXISTS t_order_1 ( order_id BIGINT NOT NULL, user_id BIGINT NOT NULL, amount DECIMAL(10, 2) DEFAULT 0, status INT DEFAULT 0, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (order_id) ) ENGINE=InnoDB;

这里用了ds0、ds1两个库，库内是t_order_0、t_order_1两张表，总共4个数据节点。主键用BIGINT，因为要配合分布式主键生成，INT很快就不够用了。

工程依赖上，我用的是Spring Boot 2.x + ShardingSphere 5.1.1。依赖长这样：

<dependency> <groupId>org.apache.shardingsphere</groupId> <artifactId>shardingsphere-jdbc-core-spring-boot-starter</artifactId> <version>5.1.1</version> </dependency> <dependency> <groupId>com.mysql</groupId> <artifactId>mysql-connector-j</artifactId> <scope>runtime</scope> </dependency>

注意版本兼容性。ShardingSphere的版本和Spring Boot有对应关系，5.1.x配Spring Boot 2.x是比较稳的组合。如果用了Spring Boot 3.x，需要确认所选ShardingSphere版本对Jakarta命名空间的支持情况，这部分踩坑的人不少。

3.2 分片规则核心配置逐行说明

ShardingSphere 5.x的配置集中在spring.shardingsphere下。一份最小可用配置如下：

spring: shardingsphere: datasource: names: ds0, ds1 ds0: type: com.zaxxer.hikari.HikariDataSource driver-class-name: com.mysql.cj.jdbc.Driver jdbc-url: jdbc:mysql://localhost:3306/ds0?serverTimezone=Asia/Shanghai&useSSL=false username: root password: root ds1: type: com.zaxxer.hikari.HikariDataSource driver-class-name: com.mysql.cj.jdbc.Driver jdbc-url: jdbc:mysql://localhost:3306/ds1?serverTimezone=Asia/Shanghai&useSSL=false username: root password: root rules: sharding: tables: t_order: actual-data-nodes: ds$->{0..1}.t_order_$->{0..1} table-strategy: standard: sharding-column: order_id sharding-algorithm-name: t_order_hash_mod key-generate-strategy: column: order_id key-generator-name: snowflake sharding-algorithms: t_order_hash_mod: type: HASH_MOD props: sharding-count: 4 key-generators: snowflake: type: SNOWFLAKE props: sql-show: true

逐行解释一下。

actual-data-nodes: ds$->{0..1}.t_order_$->{0..1}定义了数据节点映射。行表达式里的{0..1}是ShardingSphere的行表达式语法，表示展开成0、1两个下标，最终生成4个节点。

table-strategy下配置的是分表策略，sharding-column: order_id表示分片键是order_id，sharding-algorithm-name引用下面的算法定义。这里用的是HASH_MOD，对order_id做哈希后取模。sharding-count: 4表示总数4个物理表，这个值必须和actual-data-nodes里的物理表数量对齐，多出来或少了都会有问题。

key-generate-strategy是分布式主键生成策略，让中间件在插入时自动填充order_id，不需要业务手填。snowflake是ShardingSphere内置的雪花算法实现。

props.sql-show: true开启SQL日志，启动后能看到每条逻辑SQL被改写成哪些物理SQL，排查路由问题第一件事就是开这个开关。

3.3 分布式主键方案

分库分表后，数据库自增主键就不能用了。多个分片各自自增，会产生大量重复主键，业务上根本没法用。分布式主键要满足几个要求：全局唯一、趋势递增、生成性能高。

ShardingSphere默认提供SNOWFLAKE算法。雪花算法的64位结构通常是：1位符号位 + 41位时间戳 + 10位机器ID + 12位序列号。它的问题经常出现在机器ID配置和时钟回拨上。如果部署环境没正确设置worker-id，多个实例生成的ID可能冲突。时钟回拨会导致ID重复或乱序，需要业务层做兜底。

在配置里用snowflake即可，也可以手动设置props里的worker-id。对于订单表这种高频写入的大表，雪花算法生成的是64位长整型，所以物理表主键必须用BIGINT，这是设计阶段就该定好的。

3.4 验证数据落到哪张表

配置不是配完就完事了，一定要验证路由是否正确。写一个简单的Service：

@Service public class OrderService { @Resource private OrderMapper orderMapper; public void insertDemo() { for (int i = 0; i < 20; i++) { Order order = new Order(); order.setUserId((long) (i % 10)); order.setAmount(new BigDecimal("100")); order.setStatus(1); orderMapper.insert(order); } } public void queryDemo(Long orderId) { Order order = orderMapper.selectById(orderId); System.out.println(order); } }

插入时不需要手动赋值orderId，因为配置了key-generate-strategy，中间件会在执行前自动生成主键值。

插入之后，分别到ds0、ds1里执行SHOW TABLES，再分别统计t_order_0和t_order_1的行数，会看到数据大致是分散开的。HASH_MOD的好处就是分布相对均匀，不会出现一张表巨多、另一张表空着的情况。

再验证查询。执行SELECT * FROM t_order WHERE order_id = ?，看日志里实际路由到的是哪张物理表。如果日志显示SELECT * FROM t_order_0 WHERE order_id = ?，说明路由成功。如果日志里出现了所有分片的SQL，说明WHERE没带上分片键，或者分片键解析失败。

4. 分片算法的选型：不同业务字段和场景该用哪一个

4.1 高频分片算法对比

ShardingSphere内置了多个分片算法，名字很容易混淆，但每个算法解决的问题其实很明确。

算法类型	代表性type	适用场景	主要注意事项
取模分片	MOD	整型分片键，数据分布均匀	扩容时数据要大量迁移
哈希取模	HASH_MOD	字符串、雪花ID等不均值的字段	先哈希再取模，可规避ID尾部规律
范围分片	RANGE	按数值区间分片，如金额区间	容易产生热点分片
时间区间分片	INTERVAL	按时间字段分片，如月度表	时间字段必须能解析，历史冷热分离
复合分片	COMPLEX	多个分片键组合路由	需要自己实现算法类
行表达式分片	INLINE	简单场景快速配置	只支持Groovy表达式，不适合复杂逻辑

MOD是对分片键直接取模。它简单、直观、计算快，但要求分片键的值本身分布均匀。雪花ID这种高64位随时间递增、低64位带序列号的值，直接MOD会出问题：同一时间段内生成的ID后缀规律性强，算出来的取模结果会集中到少数几个分片，早期分片数据暴涨，后面分片空转。

HASH_MOD是对分片键先做哈希，再取模。它能打散不规律的值，适合字符串分片键，也适合雪花ID。ShardingSphere里配置方式是type: HASH_MOD，props.sharding-count还是分片总数。可选地，hashAlgorithmName可以指定哈希算法，比如MD5、SHA-256等，默认是MD5。

RANGE和INTERVAL适合有明显时间或数值范围的业务，比如日志表按月分片。这类算法的好处是查询时间范围时可以精准路由，坏处是写热点集中在最新分片。对新写入来说，所有流量都打到最新一个月的数据节点上，本质上和单库没有区别，需要配合读写分离或冷热分离设计。

COMPLEX适合没法用单一字段决定路由的场景，比如同时要按user_id和order_id路由。痛点是要自己实现ComplexKeysShardingAlgorithm接口，代码量不小。

4.2 字段不同，选型完全不同

选分片算法前先问一个问题：业务上最重要的查询维度是什么？

如果订单系统的核心查询是“按用户查订单”，分片键选user_id，MOD或HASH_MOD都可以，因为user_id在业务上是随机的，天然分布均匀。这样WHERE user_id = 123能精准落到一个分片，查询速度飞快。

如果核心查询是“按订单号查订单”，比如第三方回调按订单号更新状态，分片键选order_id。如果用雪花ID，就建议HASH_MOD而不是MOD，避免时间序列导致的分布倾斜。

如果是日志类系统，核心查询通常是“按时间范围查”，分片键选时间字段，用INTERVAL算法，按月或按周分片。但要注意写入热点问题，日志这类只追加数据的业务，永远在写最新一个分片，靠分片并不能解决写入单点瓶颈，只能解决存储和查询的隔离。

如果分片键本身无法覆盖所有高频查询，就接受“部分查询全路由”的现实，然后从其他环节补偿。比如用户中心按user_id分片，但后台需要按手机号精确查用户，这种查询只能全路由，或者引入一份以手机号为维度的索引映射表。

4.3 读写分离 + 分片组合配置

单库压力往往不只是数据量，还有读并发。分片之后如果每个分片还想配只读副本，就需要读写分离和分片组合使用。

ShardingSphere里读写分离是独立的一组规则。大致思路是：先用readwrite-splitting规则定义一个逻辑数据源，里面配置writeDataSourceName和readDataSourceNames，然后分片规则的actual-data-nodes里引用这个逻辑数据源。

配置结构大概是：

rules: readwrite-splitting: >