把决策翻译成配置
前面五篇把分库分表的「决策层」讲完了：拆不拆、怎么切、分片键是谁、路由放哪儿。本篇进入「实施层」——用 ShardingSphere-JDBC（下称 SS-JDBC）把方案落成代码。它是 Apache ShardingSphere 的 JDBC 增强，以 jar 包形式嵌在应用进程里，正好是第 6 篇说的 SDK 落法。接入的目标场景沿用前文的例子：订单表按 user_id 取模，8 库 32 表（每库 4 张，总 32 slot 映射）。
第一步：引入依赖，声明真实数据源
引入 shardingsphere-jdbc-core-spring-boot-starter（版本以官方文档为准），然后把 8 个真实 MySQL 数据源声明出来——每个就是普通的 JDBC 连接参数，名字叫 ds0 到 ds7：
spring:
shardingsphere:
datasource:
names: ds0,ds1,ds2,ds3,ds4,ds5,ds6,ds7
ds0: &ds0
type: com.zaxxer.hikari.HikariDataSource
driver-class-name: com.mysql.cj.jdbc.Driver
jdbc-url: jdbc:mysql://10.0.0.1:3306/order_db_0
username: order
password: ***
# ds1~ds7 同构，连接不同实例……这一步没有魔法，就是普通的连接池声明。真正的心智转变在下一步：业务代码从此不再写真实表名。
第二步：逻辑表与分片规则
业务与 SQL 里只出现「逻辑表」t_order，它在物理上对应 8 个库里的 t_order_0 ~ t_order_3（每库 4 张）。规则声明三件事：真实节点、分片列、算法：
rules:
sharding:
tables:
t_order:
actual-data-nodes: ds$->{0..7}.t_order_$->{(0..3)} # 真实节点
database-strategy:
standard:
sharding-column: user_id
sharding-algorithm-name: order-db-inline
table-strategy:
standard:
sharding-column: user_id
sharding-algorithm-name: order-table-inline
sharding-algorithms:
order-db-inline:
type: INLINE
props:
algorithm-expression: ds$->{user_id % 8} # 库路由
order-table-inline:
type: INLINE
props:
algorithm-expression: t_order_$->{(user_id % 32) intdiv 4} # 表路由逐项对应前文的决策：actual-data-nodes 是第 3 篇的拆分矩阵，sharding-column 是第 5 篇的分片键，两个 INLINE 表达式是第 4 篇的 Hash 刀法（先按 user_id 定库，再用槽位定表，槽位思想为扩容留余地）。配置完，一条普通的 insert into t_order ... 进来，SS-JDBC 自动改写成 insert into t_order_2 (于 ds5) 执行——业务代码一行没变。
接入时最容易踩的四个坑
实战里新人栽过的坑集中四处。SQL 里写死真实表名——写 t_order_2 直接绕过路由规则，数据散落在不确定的分片上；不带分片键的查询——where status = 1 这种语句会广播到全部 8 库 32 表再归并，慢查询警报拉响（第 9 篇细讲）；自增主键——各分片独立自增必然冲突，主键要换成分布式 ID 方案（第 12 篇）；事务边界——SS-JDBC 默认把跨分片事务拆成多个本地事务，一致性要靠第 11 篇的方案补。建议上线前把 show 语句、日志里的实际路由结果核对一遍——确认每条 SQL 落在预期分片，再放真实流量。
配置跑起来只是第一层。SQL 进来之后，SS-JDBC 内部到底发生了什么——解析、路由、改写、执行、归并的五步流水线，下一篇拆开看，看懂了它，大多数诡异问题都能自己定位。
评论 (0)