sharding-jdbc 绑定表

在 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_idsharding-algorithm-name: db_order_inlinetable-strategy:standard:sharding-column: order_idsharding-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_idsharding-algorithm-name: db_order_inline  # 与 t_order 的库分片算法一致table-strategy:standard:sharding-column: order_idsharding-algorithm-name: table_order_inline  # 与 t_order 的表分片算法一致# 分片算法（库级和表级）sharding-algorithms:# 库分片算法：order_id % 4 决定库索引db_order_inline:type: INLINEprops:algorithm-expression: order_db_${order_id % 4}# 表分片算法：order_id % 4 决定表索引（每个库内有 4 张本地表）table_order_inline:type: INLINEprops: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;  -- 包含分片键条件

路由逻辑

1. ShardingSphere 解析 SQL，提取分片键 order_id=100。
2. 根据绑定表配置，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。
3. 最终在 order_db_2 库中执行本地关联查询（t_order_2 和 t_order_item_2），无需跨库。

五、绑定表 vs 全局表

特性	绑定表	全局表
数据存储	分片存储（每个库仅存部分数据）	全量存储（每个库存完整数据）
适用场景	大表关联（如订单与订单项）	小表关联（如用户字典、配置表）
存储冗余	无冗余	高冗余（所有库存储全量数据）
路由规则	分片键和算法一致，路由到同一库	无需分片，所有库均有数据

六、注意事项

1. 分片键与算法必须一致：绑定表的分片键（如 order_id）和分片算法（库/表策略）必须完全相同，否则无法路由到同一库。
2. SQL 需包含分片键：关联查询的 WHERE 条件必须包含分片键（如 order_id），否则 ShardingSphere 无法确定路由目标，可能触发全库扫描。
3. 多表绑定：支持多个表绑定（如 t_order、t_order_item、t_order_log 均绑定），但需确保所有表的分片规则一致。
4. 结果合并：ShardingSphere 会自动合并跨库结果，但复杂关联（如多表排序、分页）需测试验证性能。

总结

绑定表是 ShardingSphere-JDBC 解决跨库表关联查询的核心机制，通过强制分片键和算法一致的表路由到同一物理库，实现高效本地关联。适用于大表之间的关联场景（如主子表），避免了全局表的存储冗余，同时提升了查询性能。配置时需确保分片规则一致，并在 SQL 中包含分片键条件。