java

关注公众号 jb51net

关闭
首页 > 软件编程 > java > Java中sharding-jdbc 绑定表

Java中sharding-jdbc 绑定表的实现

作者：_Jimmy_

绑定表是 ShardingSphere-JDBC 解决跨库表关联查询的核心机制,通过强制分片键和算法一致的表路由到同一物理库,实现高效本地关联,适用于大表之间的关联场景,避免了全局表的存储冗余,下面就来详细的介绍一下如何使用,感兴趣的可以了解一下

在 ShardingSphere-JDBC 中，绑定表（Binding Table） 是解决跨库表关联查询的核心机制之一，主要用于优化分片键相同、分片规则一致的表之间的关联查询性能。通过绑定表，ShardingSphere 可以将关联的两张表路由到同一个物理库，实现本地关联，避免跨库查询的开销。

一、绑定表的定义与核心作用

1. 定义

绑定表是指分片键相同、分片算法一致的两张或多张表。ShardingSphere 会基于分片键的路由结果，将这两张表映射到同一个物理库的本地表，确保关联查询可以在本地完成。

2. 核心作用

二、绑定表的典型场景

最常见的是主子表关联（如订单表与订单项表），两者通常以相同字段（如 order_id）作为分片键，且分片规则一致。例如：

此时，若直接关联查询 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. 场景说明

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. 关键配置说明

四、绑定表的关联查询验证

配置完成后，执行关联查询 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 中包含分片键条件。

到此这篇关于Java中sharding-jdbc 绑定表的实现的文章就介绍到这了,更多相关Java中sharding-jdbc 绑定表内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

您可能感兴趣的文章:
阅读全文