Java中sharding-jdbc 绑定表的实现_Java

在 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 会自动合并跨库结果，但复杂关联（如多表排序、分页）需测试验证性能。