数据库扛不住流量的时候大家第一反应往往是“分库分表”。可真到了动手环节一堆细节问题全冒出来了路由规则怎么写才不发散跨节点 JOIN 怎么处理全局主键怎么生成分布式事务怎么保证不出错每一样都能让人盯到半夜。Apache ShardingSphere 就是来解决这些问题的——一套开源的分布式数据库中间件方案把分片、读写分离、分布式事务、数据加密整合成标准能力应用层改动很小就能从单库切到多库多表。这篇文章我把 ShardingSphere-JDBC 和 Proxy 两种形态都摸过的实际经验整理出来从设计思路讲到落地配置再到生产环境最常见的坑和优化手段。如果你正准备给业务做分库分表或者已经在用 ShardingSphere 但总感觉理解得不够透这篇内容应该能帮你省下不少弯路。1. 为什么把 Apache ShardingSphere 作为分布式数据库中间件的首选1.1 单库瓶颈什么时候该考虑分库分表从实际经验看单库出问题不是突然的。一般先出现的是连接数告警和慢 SQL接着磁盘 IO 和 CPU 持续走高等到数据量到了千万级甚至亿级即使索引建得再精细性能也很难压下去。这时候分库分表不是炫技而是被业务逼出来的路线。我判断是否要拆库拆表主要看三条标准单表数据量超过千万并且还在快速增长、核心接口的响应时间开始不稳定、垂直拆分比如把订单和用户分开已经做过但仍然扛不住。把这三条摆出来项目组内部才好达成共识否则分库分表带来的复杂度会让后续所有人难受。分库分表本质上是把一个“大收银台”拆成多个“小收银台”每个台子服务一部分顾客。容量问题解决了但新问题也来了——顾客要同时排多个队得有一个调度系统知道队列分布在哪里。这正是数据库中间件存在的理由它负责所有人都不愿意碰的那层脏活累活。1.2 JDBC、Proxy、Sidecar 三种形态到底怎么选ShardingSphere 的产品矩阵主要有三种形态。ShardingSphere-JDBC 是一个 Java 的 JAR 包嵌入在应用进程里通过 DataSource 包装原数据源适合 Java 技术栈性能开销最小链路最直接ShardingSphere-Proxy 则是一个独立部署的代理进程对外暴露 MySQL 和 PostgreSQL 协议业务端不用改任何代码把它当成一个数据库地址连就行特别适合非 Java 应用或者 DBA 主导的团队Sidecar 形态目前更多是云原生方向的探索独立部署的 mesh 方案落地场景不算多。我的建议是如果团队能控制应用层代码且是 Java 系优先 JDBC如果团队里有专门的 DBA想把这层中间件像数据库一样统一管理或者业务是多语言异构选 Proxy。很多团队最终会两条腿走路JDBC 给核心交易服务Proxy 给报表、运维工具这类对连接协议敏感的入口。两种形态本身没有高下之分关键看谁来运维、谁来改代码。1.3 不自己写路由引擎的核心理由可能有团队想过自己封装一套分库分表逻辑拿到 SQL解析出表名再拼一个物理表名出来。这个思路听上去简单但真正做起来会陷得很深。分库分表的本质是三个问题SQL 怎么解析、数据怎么路由、结果怎么归并。自己写一个能处理 JOIN、子查询、聚合函数、分页的 SQL 解析器工作量远超想象仅解析一段 SQL 就要处理 MySQL、PostgreSQL、openGauss 多种方言还要兼容?占位符和 Java 的PreparedStatement参数化查询每增加一种语法都是新坑。ShardingSphere 把这条链路已经沉得很深SQL 解析、改写、路由、归并、执行都有现成的抽象层社区版就能覆盖绝大多数业务场景。更实在的是生态它跟 Spring Boot、MyBatis、HikariCP 这些基础设施的整合很顺官方文档对常见数据库和中间件版本都做过兼容性验证。自己在业务里造轮子第一期也许能用到后来接数据迁移、做高可用、踩协议坑的时候成本会指数级上升。2. 核心功能拆解分片、主键、事务、加密与读写分离2.1 分片策略行表达式和四种自定义算法分片是整个中间件的核心。ShardingSphere 5.x 里配置分片算法常见有 INLINE、MOD、HASH_MOD、RANGE、INTERVAL、COMPLEX 等。INLINE 是行表达式简单直观t_order_$-{order_id % 2}表示按订单号除以 2 取余选择表。MOD 和 HASH_MOD 的区别在于MOD 直接对分片键取模HASH_MOD 先对字符串等非数值类型做哈希再取模。分片键如果是字符串类型比如订单号带业务前缀必须用 HASH_MOD 而不是 MOD不然所有相同前缀的数据会集中到同一个节点。COMPLEX 用于多个分片键的复合规则HINT 用于不走 SQL 参数、而是通过 ThreadLocal 方式强制指定路由的场景。实际项目里九成以上用 INLINE 就够了剩下的再考虑标准算法和复合算法。配置分片算法时有一个高频错误分片键被随便选。规则是——包含分片键的 SQL 才能精确路由不带分片键的 SQL中间件只能走全库全表路由然后全量归并性能直接崩。所以分片键必须是你查询频率最高的字段而不是你看哪个字段顺眼就选哪个。2.2 分布式主键别让雪花算法栽在时钟回拨上分库分表之后数据库自增主键一定会重复必须由中间件层生成全局唯一 ID。ShardingSphere 默认提供的 SNOWFLAKE 算法生成 64 位 long 型 ID结构是时间戳加机器标识加序列号。它的优点是趋势递增、性能高但有个经典坑时钟回拨。如果操作系统时间往回跳同一毫秒内序列号可能重复生成的主键就会冲突。ShardingSphere 的做法是在检测到回拨时阻塞等待到下一个毫秒但阻塞会导致应用线程卡住。我在生产环境就遇到过因为 NTP 同步导致主键重复排查到源头是时钟回拨的问题。我的建议第一不同实例必须配置唯一的机器标识不能图省事全用默认值第二如果并发量特别大或者对 ID 要求绝对唯一可以换成自定义 KeyGenerator比如号段模式或者直接用 UUID。但要清楚 UUID 不是趋势递增对 InnoDB 索引会有随机写开销。顺序 ID 和随机 ID 的选择本质上是在插入性能和外部可用性之间做权衡。2.3 分布式事务XA 和 BASE 柔性事务的取舍分布式事务是分库分表绕不过去的坎。ShardingSphere 5.x 支持两种模式XA 强一致事务基于两阶段提交协议适合金融类对一致性要求极高的场景SEATA 柔性事务适合允许最终一致、追求吞吐的业务。XA 的实现原理是事务管理器先让所有参与分支 prepare全部成功后再 commit任一失败则统一 rollback。强一致但有锁定资源时间长的毛病高并发下容易互相阻塞。SEATA AT 模式则通过业务逻辑层的事务协调器管理分支提交状态框架层做补偿性能比 XA 好。在 ShardingSphere 中使用分布式事务只需要在服务方法上加注解指定事务类型再叠加 Spring 的Transactional即可。但我必须提醒一点中间件解决了事务框架的接入不代表业务的兜底设计可以省略。真要出问题手工对账和补偿脚本始终是最后一道防线这一点在任何分布式系统里都一样。2.4 数据加密、脱敏和读写分离的典型配置很多敏感字段比如身份证号、手机号落库前需要加密。ShardingSphere 通过 encrypt 规则可以在写入时加密、查询时自动解密业务代码无感知。配置里需要声明逻辑列名和密文列名比如逻辑列phone密文列phone_cipher加密算法用 AES。这套能力对数据安全合规很省力但也容易踩一个深坑已经明文存在库里的老数据需要先做一次数据迁移把明文刷到密字段才能切换规则否则一查全是乱码。读写分离的配置相对简单在主从架构上声明一个 master 数据源和多个 replica 数据源SQL 按照规则自动分流。查询一致性要求高的场景可以让同一线程内强制走主库否则可能出现主从延迟导致的“刚写完读不到”。这个坑在运维那里最典型表现为用户刚提交订单就刷新结果订单消失了几秒排查半天发现是读到了从库的旧数据。3. 实操落地用 ShardingSphere-JDBC 给订单表做分库分表3.1 环境准备依赖引入与版本选择我用 Spring Boot 2.7 加 MyBatis 的环境做演示。首先要引入依赖dependency groupIdorg.apache.shardingsphere/groupId artifactIdshardingsphere-jdbc-core-spring-boot-starter/artifactId version5.4.1/version /dependency版本选择上有一个明显的分水岭4.x 的配置风格和 5.x 完全不兼容5.x 把规则收敛成了rules结构算法统一用type props形式。如果你看到网上教程里写的是sharding.jdbc.config.sharding那是 4.x 老写法直接照搬到 5.x 会报错。新项目直接用 5.x 最新稳定版就对了4.x 只在维护老系统时才需要考虑。3.2 数据节点设计分几库、分几张表最合理分库分表最忌讳拍脑袋。先想清楚扩容策略是“一开始分了 4 个库以后不再扩容”还是“明年数据量翻一倍要能平滑扩到 8 个库”。如果是后者取模规则要设计成 2 的幂次比如 4 库 4 表变成 8 库 8 表时老数据还能通过二次迁移映射到新规则相对可控如果用了随意数字取模后续扩容几乎等于重写路由。我做过的一个订单项目设计是 2 个库、每库 4 张表分库键用user_id分表键用order_id。这样设计的原因是订单查询的高频场景是“查某用户的订单列表”用 user_id 分库能保证同一个人的订单落在一个库里order_id 分表则让单个库内数据量可控也方便关联订单明细表。3.3 完整 YAML 配置与每个参数的落地含义在application.yml中配置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 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 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_inline key-generate-strategy: column: order_id key-generator-name: snowflake binding-tables: - t_order, t_order_item broadcast-tables: - t_config default-database-strategy: standard: sharding-column: user_id sharding-algorithm-name: ds_inline sharding-algorithms: ds_inline: type: HASH_MOD props: sharding-count: 2 t_order_inline: type: INLINE props: algorithm-expression: t_order_$-{order_id % 4} key-generators: snowflake: type: SNOWFLAKE props: sql-show: true sql-simple: true几个关键点解释一下。actual-data-nodes决定最终物理表ds$-{0..1}.t_order_$-{0..1}的意思是在 ds0 和 ds1 两个库里各有t_order_0到t_order_1四张物理表。table-strategy声明的是表级分片逻辑default-database-strategy是库级分片逻辑。这里有个理念要理解清楚ShardingSphere 的分片是两个维度的组合先按库策略选出一个库再按表策略在库内选一张表。所以写 SQL 时要尽量把两个分片键都带上。3.4 代码集成Mapper 和 SQL 怎么写才能正确路由配置好之后业务代码的写法变化不大。Mapper 里依然写INSERT INTO t_orderShardingSphere 会把它改写成实际的物理表。下面是 MyBatis 的一个典型写法insert idinsert INSERT INTO t_order (order_id, user_id, amount) VALUES (#{orderId}, #{userId}, #{amount}) /insert插入的关键是order_id不能由数据库自增而要由 KeyGenerator 生成后传入。我在项目里的做法是服务层先主动获取一个分布式 ID再组装实体插入这样后续写缓存、发异步消息也能带上同一个业务主键。查询时WHERE user_id ?能命中库级路由WHERE order_id ?能命中表级路由。如果只带 order_id 不带 user_id中间件会先扫描 ds0 和 ds1 两个库再在各自库里定位一张表轻量但已经跨库了如果只带 user_id则只查某一个库但会扫该库全部 4 张表。这两类查询在生产环境要尽量避免它们是半路由状态性能不如完整路由。3.5 验证结果如何确认数据真的分布均匀配置完成之后的第一件事不是写业务而是验证分布。我会建一张空表用脚本插入 100 条测试数据然后分别登录 ds0 和 ds1执行SELECT COUNT(*) FROM t_order_0这类语句确认每个分片的数据量差不多没有单库全量堆积的情况。接着验证查询路由开启sql-show: true后日志里能看到 SQL 改写后的真实语句比如SELECT * FROM ds0.t_order_0或者ds1.t_order_2这最能直观地确认路由是否正确。注意ShardingSphere 默认不会自动建物理表。分片表需要在每个库中都提前建好比如两个库各建t_order_0和t_order_1共 4 张物理表。我见过不只一次因为漏建某张分片表导致线上数据写入报“表不存在”的事故。4. 踩坑实录最常见的 5 类问题与性能调优4.1 常见问题速查表现象、根因、解法现象根因解法执行 SQL 报路由失败WHERE 里没有分片键查询条件必须带上分片键实在无法带考虑 HINT 强制路由主键重复、插入报唯一键冲突时钟回拨或机器标识配置一样检查时钟同步给不同实例配置唯一机器标识跨表 JOIN 结果错误关联表没声明绑定关系配置binding-tables让相关联的物理表一一映射深分页LIMIT 100000, 10响应极慢多库多表归并导致大量无用数据传输改成“上一页最大 ID”方式或限制单页深度刚写入的数据查不到主从延迟读写分离场景下关键接口强制走主库4.2 原理级避坑绑定表、广播表和全路由绑定表解决的是分库分表后 JOIN 的经典难题。订单表和订单明细表都按order_id分片时如果不声明绑定关系一次 JOIN 可能会对面表做全库全表扫描声明了t_order, t_order_item绑定之后ShardingSphere 会把两张表的路由结果对齐只查同一个节点上的对应表。广播表则适用于配置类数据比如全局字典表每个分片库里都放一份完整副本查询走本地节点避免跨库 JOIN。另一个常被忽略的点是全库路由。开发环境数据量小SQL 不带分片键也能跑看起来一切正常。等上了生产一个不带分片键的定时任务可能瞬间打满所有数据库连接。我踩过这个坑一个统计接口按create_time查询全部分片的数据某次数据量上来后一下子把两边数据源连接池全部耗尽。后来的做法是一次性清洗或统计查询先汇总到单独的数据仓库业务库只做单点精确查询。4.3 性能调优从连接池到 SQL 归并的优化路径连接池参数要结合分片数量调整。ShardingSphere 一次逻辑查询可能会在多个物理节点上执行如果应用连接池最大连接数设得太小并行子查询会把连接耗尽。我的经验是maximum-pool-size至少不小于最大分片数HikariCP 的max-lifetime要略小于数据库的连接超时时间避免连接被数据库端回收后应用还在继续使用。SQL 层面能省则省。能拆分开的统计先拆分非必要的排序、聚合尽量放在业务侧做让 ShardingSphere 只负责数据收敛而不是复杂归并。比如 TOP-N 查询尽量在每个分片上先做一次子查询归并时只处理 N 条而不是全量拉取后再排序。索引设计也要跟着分片键走既然表已经按 order_id 路由那么 order_id 必须建索引user_id 是分库键每个分片的表上也必须有索引否则“查某用户订单”这种高频场景会变成每个分片全表扫描。脑子里的模型应该是分片键索引和业务索引配合而不是只在物理表主键上建索引。4.4 监控与巡检分库分表之后的运维习惯不要以为接入中间件后 DBA 就可以下班。分库分表之后的运维重点已经转移到数据分布、连接池指标和 SQL 路由日志这三件事。ShardingSphere 自带 metrics 和日志追踪可以接入常见监控体系重点看三个指标单库 QPS 是否均衡、慢 SQL 是否集中在某个分片、SQL 改写日志是否出现了预期之外的全路由。我还会定期跑一个数据分布巡检脚本统计各分片行数偏差超过 20% 就复盘分片键设计。HASH_MOD 在数学上是均匀的但业务数据的冷热分布决定了总量可能不均。比如订单表按用户 ID 分片一部分大客户订单量特别高数据就会倾斜。巡检能提前发现隐患而不是等某个分片磁盘满了才去处理。我个人这些年在分库分表上最大的体会是中间件能帮你解决路由、事务这些工程问题但它不能替代架构设计本身。分片键选得对不对、数据节点设计得合不合理、是否存在必须全路由的统计查询这些决策比中间件本身的配置重要得多。刚开始接分库分表时我也以为 YAML 配置跑通就算成功了后来发现真正的功夫全在 SQL 治理和数据分布的把控上。最后分享一个小技巧分库分表上线前至少要演练一次“一台分片库宕机”的场景。手动停掉一个分片库看应用报错是否清晰、链路能否自动重连、读写分离是否切到了剩余副本。很多问题不演练根本发现不了等真出故障再排查代价就是线上事故的等级了。
