分库分表这件事说实话我是能躲就躲的态度。业务量真到了单库单表撑不住的时候不做又不行。这篇就把我用ShardingSphere落地分库分表和读写分离的完整过程捋一遍——从选型到配置从踩坑到排查尽量把普通文档里不会写的内容都整理出来。如果你正在评估要不要上分片或者已经被分配了数据库改造任务这篇文章应该能帮你少走不少弯路。这里重点聊ShardingSphere-JDBC模式它和Spring Boot业务系统配合起来最省事也是大多数项目的实际选择。1. 为什么需要分库分表和读写分离问题拆解与方案选型1.1 单库单表撑不住时到底发生了什么我见到很多团队是在业务已经明显报警之后才开始认真考虑分库分表的。单表数据量到了千万级甚至亿级之后问题不是某一个点而是全身性发作普通索引的B树高度增加一次查询的随机IO次数变多慢SQL从偶尔出现变成常态写入侧同样难受单表的行锁和间隙锁竞争加剧并发稍高就尸横遍野。更隐蔽的是日常运维——一个几亿行的表做一次DDL加字段在原库上可能跑几十分钟甚至更久期间锁表风险极高。这些问题的本质是单节点数据库的算力、存储和IO都到了瓶颈。有人会说加SSD、加内存、上更强配置的机器这是最省事的思路但单机总有上限而且最贵的那一档配置性价比极低。真正要决策的是到底靠优化就能撑还是必须要走分片路线。我的判断标准很简单也很粗暴单表行数超过一千万且月增长超过三五百万、同时读并发超过每秒几千、或者写入峰值经常打满单库IO这三个条件满足两个就值得认真评估分库分表了。如果只是偶尔一条慢SQL先优化索引和SQL更划算。1.2 分库分表和读写分离各解决哪一类问题很多人把分库分表和读写分离混为一谈其实是两个维度的事。分库分表解决的是数据量太大和并发写入太高数据量大了单表查询和写入都慢于是把数据按照某个维度拆到多个库多个表里每个分片只承担一部分数据和流量。读写分离解决的是读多写少场景下单库的读压力过大把所有写请求打到主库读请求分散到多个从库让主库从读流量里解放出来。它们在架构上是完全独立的两个问题但ShardingSphere把它们统一在一个配置文件里这也是它上手快的原因之一。用生活类比来讲分库分表是把一个大仓库拆成多个小仓库每个仓库只存一类货读写分离是给主仓库开了几家只读分店顾客看货去分店真正入库单只有主仓库能签收。一个解决存量数据膨胀一个解决流量洪峰两者可以叠加使用。1.3 为什么选ShardingSphere-JDBC而不是其他方案分库分表的实现路径大致有四条一是应用层自己封装数据源路由二是用ShardingSphere这类专业中间件三是用开源数据库中间件比如MyCat四是直接选择分布式数据库如OceanBase、TiDB。应用层自己封装的方案我见过不少初期确实灵活但后期维护成本极高特别是分片算法一变业务代码要跟着改路由逻辑和业务逻辑耦合之后没人敢动。ShardingSphere-JDBC本质是一个增强版数据源——它把自己伪装成一个标准的数据源业务层完全无感知SQL进来之后由它完成解析、路由、改写、执行和结果归并。这个模式最大的优势是不需要额外部署服务跟着应用一起启动故障域天然隔离。对比Proxy模式JDBC模式少了一层网络开销在绝大多数场景下延迟更低排查问题也更直接因为所有逻辑都在应用内。而MyCat这类中间件由于核心是拦截MySQL协议做转发对复杂SQL的兼容性处理精细度相对有限。还要考虑团队的可维护性。ShardingSphere有大量现成的分片算法、分布式ID生成器、读写分离负载均衡策略而且5.x版本之后配置维度几乎全部收敛到YAML或者注册中心逻辑表和物理表分离的设计很清晰后续交接给其他同事不至于变成遗产项目。综合来看Spring Boot ShardingSphere-JDBC是当前主流、也最稳妥的组合。2. 核心细节解析分片算法、绑定表与读写分离原理2.1 分片键是生死线算法选择要留后路分片键是分库分表方案里最先要定死的决策没有之一。分片键决定了每条数据落到哪个库哪张表它必须是所有高频查询都能携带的字段。拿最典型的订单场景来说如果按order_id分片那一切按用户维度查订单的SQL都必须先通过order_id查出来再路由或者直接全分片广播查询。一旦出现大量某用户查自己名下所有订单的请求而这些请求的SQL里又没有order_idShardingSphere只能把请求广播到所有分片然后在内存里归并结果这个成本是不可接受的。常见做法是按下单用户的user_id分片这样所有按用户查订单的SQL天然命中单个分片。如果还需要按order_id精确查询那就额外建立order_id到user_id的映射关系或者用一个冗余的映射表。鱼与熊掌不可兼得必须忍痛做取舍。分片算法上的选择更隐蔽。初次上线图省事用了取模MOD比如两个库就user_id % 2数据分布很均匀但等数据量到了需要从两个库扩到四个库的那一天所有数据的路由结果都变了——原来在库0的数据按新算法可能跑到库1老数据必须做全量迁移。所以现在我在新建项目上基本只推荐两种方案一致性哈希或者HASH_MOD。HASH_MOD是先对分片键做哈希散列再做取模比直接取模多一步但可以让原本有规律的分片键比如1、3、5、7这类递增序列在分片上分布得足够均匀。后续要从N个分片扩到N1个虽然也涉及迁移但配合虚拟节点可以把迁移范围控制在一个可接受的区间内。ShardingSphere 5.x里改分片算法的配置非常方便只需要替换algorithm类型和参数。真正的成本在于历史数据迁移所以这句话值得重复三遍分片算法选型时要考虑未来三到五年的扩容路径别为了今天省事让后天做全量重分布。2.2 绑定表和广播表解决关联查询和公共数据分库分表后最疼的问题是join。订单表拆了订单明细表也拆了但如果两张表的分片键不一致订单表按order_id、明细表按detail_id那join时跨库跨表的代价会非常恐怖。ShardingSphere提供的解法叫绑定表bindingTables。绑定表要求两个表的业务关联键一致且它们的实际分片键是同一个字段。比如t_order和t_order_item都按order_id分片那么在配置里声明bindingTables: t_order,t_order_item。这样一旦t_order被路由到某个分片t_order_item会跟着落到同一个数据源ShardingSphere在链路层就能把跨分片的笛卡尔积连接优化成单分片连接性能提升通常是数量级的。广播表这个概念则针对字典表、配置表这类数据量不大但几乎每个SQL都要join的数据。它的语义是不分片数据同步到每一个分片库。配置了broadcastTables之后ShardingSphere在写操作时会自动把数据写入所有分片读操作时随机选一个分片读取。我见过有人把所有小表都配成广播表非常不建议——广播表的每个写操作都会放大到N次写频繁的小表会变成整个分片链路里最拖后腿的东西。2.3 读写分离的工作机制与主从延迟的坑读写分离在ShardingSphere里的实现原理并不复杂。它内置了一个逻辑数据源这个数据源里面挂了一个主库和多个从库。SQL经过解析后根据语句类型自动判定路由SELECT请求路由到从库INSERT/UPDATE/DELETE请求路由到主库。在5.x版本里这属于读写分离加数据分片组合使用时的核心机制。但有一个很重要的细节事务内的读请求会被强制路由到主库。ShardingSphere知道如果事务里先写后读而读走了从库很可能会因为主从复制延迟读到旧数据导致业务逻辑错乱。这个默认行为是保护机制但有些团队在排查问题时反而被它迷惑看到事务里的SELECT走了主库就以为是配置失效其实是正确的设计。主从延迟是读写分离最大的隐患。今天我仍然会建议团队在从库上监控Seconds_Behind_Master指标一旦延迟超过阈值比如5秒就要告警。业务侧如果对数据一致性要求极高可以在关键读请求上使用Hint强制主库路由ShardingSphere提供了HintManager用法非常简单try (HintManager hintManager HintManager.getInstance()) { hintManager.setWriteRouteOnly(); // 这里面的流式查询可以配合强制主库路由 ListOrder orderList orderMapper.selectLatestOrder(userId); }ShardingSphere的Hint能力不仅用在强制主库路由还用在强制指定某个数据源进行查询比如数据订正、补偿任务等。总之方案上要做到默认读从库、事务内读主库、核心场景Hint强切主库三层防线。3. 实操落地Spring Boot ShardingSphere 完整配置3.1 依赖准备与环境搭建这个案例基于Spring Boot 2.7.x和ShardingSphere-JDBC 5.3.x来做演示。先说说版本选择的理由。5.x相比4.x在配置结构上有一次大调整分片算法、读写分离、数据加密等能力全部改成了rules下面的独立模块语义更加清晰。如果你在网上下载的项目还是4.x的配置格式必须留个心眼两种版本的YAML结构长得完全不一样。加入依赖是最简单的环节核心依赖只有一个dependency groupIdorg.apache.shardingsphere/groupId artifactIdshardingsphere-jdbc-core-spring-boot-starter/artifactId version5.3.2/version /dependency这个依赖会自动装配一个ShardingSphereDataSource业务代码像使用普通DataSource一样注入即可。需要特别强调的是决定使用ShardingSphere之后Spring Boot的数据源自动配置必须关闭否则会和ShardingSphere的数据源初始化冲突。通常在启动类或者application.yml里加一个排除配置这个细节文档里写得很含蓄但80%的启动报错都源于它。SpringBootApplication(exclude {DataSourceAutoConfiguration.class}) public class OrderApplication { public static void main(String[] args) { SpringApplication.run(OrderApplication.class, args); } }3.2 分库分表核心配置逐行解读下面的配置是我在一套模拟订单场景中的完整分库分表配置两个库、每个库两张分表以user_id作为库分片键以order_id作为表分片键。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/order_db0?useSSLfalseserverTimezoneAsia/Shanghai username: root password: root123 ds1: type: com.zaxxer.hikari.HikariDataSource driver-class-name: com.mysql.cj.jdbc.Driver jdbc-url: jdbc:mysql://localhost:3306/order_db1?useSSLfalseserverTimezoneAsia/Shanghai username: root password: root123 rules: sharding: tables: t_order: actual-data-nodes: ds$-{0..1}.t_order_$-{0..1} database-strategy: standard: sharding-column: user_id sharding-algorithm-name: db_mod table-strategy: standard: sharding-column: order_id sharding-algorithm-name: table_hash_mod key-generate-strategy: column: order_id key-generator-name: snowflake binding-tables: - t_order,t_order_item broadcast-tables: - t_dict sharding-algorithms: db_mod: type: HASH_MOD props: sharding-count: 2 table_hash_mod: type: HASH_MOD props: sharding-count: 2 key-generators: snowflake: type: SNOWFLAKE props: worker-id: 1 props: sql-show: true逐段解释一下关键点。actual-data-nodes支持非常灵活的表达式ds$-{0..1}.t_order_$-{0..1}展开后就是ds0.t_order_0、ds0.t_order_1、ds1.t_order_0、ds1.t_order_1四个实际物理表。这里有一个常见的理解误区逻辑表是t_order它在业务SQL里出现物理表名带后缀它们真实存在于数据库里。ShardingSphere做的就是逻辑表到物理表的映射。分库分表策略分开配置可以做到库按用户分、表按订单分。HASH_MOD算法是先对分片键做哈希再取模我在2.1节里已经解释过为什么不用裸MOD。key-generate-strategy配置了order_id通过内置雪花算法生成分布式ID这一步对分库分表来说不是可选项——一旦分片数据库自增ID在各种实例上一定会重复用任何分布式ID方案都比自增靠谱。sql-show: true是个调试利器开启后每条SQL都会打印分片前的原始SQL和分片后的实际SQL后续排查路由问题时靠它定位最快。生产环境记得关掉日志量很大。3.3 读写分离与负载均衡配置分库分表加读写分离组合通常在两个维度上都做了冗余。下面的配置展示了如何把读写分离嵌进分片数据源里spring: shardingsphere: datasource: names: ds_master_0,ds_slave_0_0,ds_slave_0_1,ds_master_1,ds_slave_1_0 ds_master_0: type: com.zaxxer.hikari.HikariDataSource driver-class-name: com.mysql.cj.jdbc.Driver jdbc-url: jdbc:mysql://localhost:3306/order_db0 username: root password: root123 ds_slave_0_0: type: com.zaxxer.hikari.HikariDataSource driver-class-name: com.mysql.cj.jdbc.Driver jdbc-url: jdbc:mysql://localhost:3307/order_db0 username: root password: root123 ds_slave_0_1: type: com.zaxxer.hikari.HikariDataSource driver-class-name: com.mysql.cj.jdbc.Driver jdbc-url: jdbc:mysql://localhost:3308/order_db0 username: root password: root123 ds_master_1: type: com.zaxxer.hikari.HikariDataSource driver-class-name: com.mysql.cj.jdbc.Driver jdbc-url: jdbc:mysql://localhost:3309/order_db1 username: root password: root123 ds_slave_1_0: type: com.zaxxer.hikari.HikariDataSource driver-class-name: com.mysql.cj.jdbc.Driver jdbc-url: jdbc:mysql://localhost:3310/order_db1 username: root password: root123 rules: readwrite-splitting: >