分库分表先解决单库容量或吞吐瓶颈，再引入 ShardingSphere-JDBC。它嵌入 Java 应用并包装 DataSource，对 SQL 做解析、路由、改写、执行和结果归并；它不会替你选择正确的分片键。
Table of contents
Open Table of contents
先从查询反推分片键
以订单系统为例，若 90% 请求按 user_id 查询用户订单，就可按 user_id 分片。若客服必须按 order_id 查询，需要让订单 ID 编码路由信息、建立独立映射，或接受广播查询。不要同时声称两个无关字段都能精确路由。
核心术语：
- 逻辑表：应用看到的表名，如
t_order。 - 真实表：实际节点上的表，如
ds_0.t_order_2。 - 绑定表：用相同分片键与算法拆分的一组表，如订单与订单项。
- 广播表：每个数据源都有完整副本的小型参考表。
绑定表联表时必须携带绑定用的分片键，否则可能产生跨库查询或笛卡尔路由。广播表适合低频更新的字典，不适合高频余额数据。
用 Java 验证路由
分布式系统实验室的 ShardRouter下载先把 8 个槽位映射到 2 个库、每库 4 张表：
ShardRouter router = new ShardRouter(2, 4);
Route route = router.route(42); // 同一个键始终得到同一路由运行验证：
mvn -Dtest=DistributedMechanismsTest#bindingTablesUseTheSameShardKey test真实项目再按照ShardingSphere-JDBC 当前配置文档创建数据源。先在影子数据上检查等值、范围、排序、分页、聚合和 JOIN 的路由数量。
上线门槛
记录每条代表性 SQL 的目标分片数、返回行数和归并内存。禁止无分片键的大范围在线查询；为运营检索建立异步索引或离线数仓。最后演练扩容，因为取模算法从 8 改成 16 会让大量旧数据位置改变。
下一步
继续阅读08-09 ShardingSphere-Proxy、内核与扩容，理解代理模式和数据迁移。