我要评论在 shardingsphere-jdbc 中，绑定表（binding table） 是解决跨库表关联查询的核心机制之一，主要用于优化分片键相同、分片规则一致的表之间的关联查询性能。通过绑定表，shardingsphere 可以将关联的两张表路由到同一个物理库，实现本地关联，避免跨库查询的开销。
一、绑定表的定义与核心作用
1. 定义
绑定表是指分片键相同、分片算法一致的两张或多张表。shardingsphere 会基于分片键的路由结果，将这两张表映射到同一个物理库的本地表，确保关联查询可以在本地完成。
2. 核心作用
- 避免跨库关联：关联表路由到同一物理库，无需跨库网络传输。
- 提升查询性能：本地关联效率远高于跨库关联（尤其对大表）。
- 简化分片规则：无需将关联表配置为全局表（避免存储冗余）。
二、绑定表的典型场景
最常见的是主子表关联（如订单表与订单项表），两者通常以相同字段（如 order_id）作为分片键，且分片规则一致。例如：
- 订单表 t_order（分片键：order_id，按 order_id % 4 分片到 db_order_0~3）。
- 订单项表 t_order_item（分片键：order_id，按 order_id % 4 分片到 db_order_item_0~3）。
此时，若直接关联查询 t_order 和 t_order_item，shardingsphere 可能将它们路由到不同库（如 t_order 到 db_order_0，t_order_item 到 db_order_item_1），导致跨库关联。通过绑定表，可强制两者路由到同一库（如 db_order_0 和 db_order_item_0）。
三、绑定表的配置步骤
以下以 spring boot 配置为例，演示订单表 t_order 与订单项表 t_order_item 的绑定表配置。
1. 场景说明
- 逻辑表：
t_order（订单表）、t_order_item（订单项表）。 - 分片键：两者均以
order_id为分片键。 - 分片算法：均按
order_id % 4分片到 4 个库（order_db_0~3）和本地表（t_order_0~3、t_order_item_0~3）。
2. 配置文件（application.yml）
spring:
shardingsphere:
datasource:
names: order_db_0, order_db_1, order_db_2, order_db_3 # 订单库的物理库
# 省略具体数据源连接配置（每个物理库需单独配置）
rules:
sharding:
tables:
# 订单表 t_order（逻辑表）
t_order:
actual-data-nodes: order_db_${0..3}.t_order_${0..3} # 路由到 order_db 的 0~3 库，每个库有 t_order_0~3 表
database-strategy:
standard:
sharding-column: order_id
sharding-algorithm-name: db_order_inline
table-strategy:
standard:
sharding-column: order_id
sharding-algorithm-name: table_order_inline
# 订单项表 t_order_item（逻辑表，与 t_order 绑定）
t_order_item:
actual-data-nodes: order_db_${0..3}.t_order_item_${0..3} # 与 t_order 相同的库和表分片规则
database-strategy:
standard:
sharding-column: order_id
sharding-algorithm-name: db_order_inline # 与 t_order 的库分片算法一致
table-strategy:
standard:
sharding-column: order_id
sharding-algorithm-name: table_order_inline # 与 t_order 的表分片算法一致
# 分片算法（库级和表级）
sharding-algorithms:
# 库分片算法：order_id % 4 决定库索引
db_order_inline:
type: inline
props:
algorithm-expression: order_db_${order_id % 4}
# 表分片算法：order_id % 4 决定表索引（每个库内有 4 张本地表）
table_order_inline:
type: inline
props:
algorithm-expression: t_order_${order_id % 4}
# 绑定表配置（关键！）
binding-tables:
- t_order, t_order_item # 声明 t_order 和 t_order_item 为绑定表
3. 关键配置说明
- binding-tables：显式声明绑定表列表，shardingsphere 会基于此处理关联查询的路由。
- 分片策略一致：t_order 和 t_order_item 的库分片算法（db_order_inline）和表分片算法（table_order_inline）完全一致，确保它们路由到同一物理库的同一索引位置（如 order_id=100 时，均路由到 order_db_2 库的 t_order_2 和 t_order_item_2 表）。
四、绑定表的关联查询验证
配置完成后，执行关联查询 sql，验证是否路由到同一物理库。
示例 sql
select o.order_id, o.amount, i.item_id, i.product_name from t_order o join t_order_item i on o.order_id = i.order_id where o.order_id = 100; -- 包含分片键条件
路由逻辑
- shardingsphere 解析 sql，提取分片键 order_id=100。
- 根据绑定表配置，t_order 和 t_order_item 均按 order_id % 4 路由：
- 库路由：order_id % 4 = 100 % 4 = 2 → 库名为 order_db_2。
- 表路由：order_id % 4 = 2 → 表名为 t_order_2 和 t_order_item_2。
- 最终在 order_db_2 库中执行本地关联查询（t_order_2 和 t_order_item_2），无需跨库。
五、绑定表 vs 全局表
| 特性 | 绑定表 | 全局表 |
|---|---|---|
| 数据存储 | 分片存储（每个库仅存部分数据） | 全量存储（每个库存完整数据） |
| 适用场景 | 大表关联（如订单与订单项） | 小表关联（如用户字典、配置表） |
| 存储冗余 | 无冗余 | 高冗余（所有库存储全量数据） |
| 路由规则 | 分片键和算法一致，路由到同一库 | 无需分片，所有库均有数据 |
六、注意事项
- 分片键与算法必须一致：绑定表的分片键（如 order_id）和分片算法（库/表策略）必须完全相同，否则无法路由到同一库。
- sql 需包含分片键：关联查询的 where 条件必须包含分片键（如 order_id），否则 shardingsphere 无法确定路由目标，可能触发全库扫描。
- 多表绑定：支持多个表绑定（如 t_order、t_order_item、t_order_log 均绑定），但需确保所有表的分片规则一致。
- 结果合并：shardingsphere 会自动合并跨库结果，但复杂关联（如多表排序、分页）需测试验证性能。
总结
绑定表是 shardingsphere-jdbc 解决跨库表关联查询的核心机制，通过强制分片键和算法一致的表路由到同一物理库，实现高效本地关联。适用于大表之间的关联场景（如主子表），避免了全局表的存储冗余，同时提升了查询性能。配置时需确保分片规则一致，并在 sql 中包含分片键条件。
到此这篇关于java中sharding-jdbc 绑定表的实现的文章就介绍到这了,更多相关java中sharding-jdbc 绑定表内容请搜索代码网以前的文章或继续浏览下面的相关文章希望大家以后多多支持代码网！
发表评论