binding table是一组分片键、分片算法和数据节点完全对齐的逻辑绑定表，确保join可下推至单节点执行；它不是外键约束、物理合并或sql改写工具，仅影响路由决策。
ShardingSphere 的 binding table 是解决分片表间 JOIN 路由正确性与性能问题 的核心机制。它不改变 SQL 语义，而是通过逻辑约定让 ShardingSphere 确信：多张表的分片键值一致、分片规则相同、数据分布对齐。只有满足这一前提，跨表 JOIN 才能下推到单个数据库节点执行，避免广播 JOIN 或内存归并，真正实现高效路由。
binding table 是什么？不是什么？
binding table 是一组逻辑上“绑定”的分片表，它们共享相同的分片策略（包括分片键、分片算法、数据节点映射），且业务上保证关联字段值严格一致（如 order_id 和 order_item.order_id 总是同值）。它不是外键约束，不校验数据一致性；不是物理表合并，不改变存储结构；也不是自动 SQL 改写工具——它只影响路由决策。
常见误用场景：
- 把 user 表和 address 表设为 binding table，但 address.user_id 并非分片键，或分片算法与 user.id 不一致 → 路由失效，退化为笛卡尔积广播
- order 和 order_item 分片键都是 order_id，但 order 按 order_id % 4 分库，order_item 却按 order_id % 8 分库 → 数据分布错位，JOIN 结果缺失
如何正确定义 binding table？关键三要素缺一不可
必须在 sharding-rule 配置中显式声明，并确保以下三点完全对齐：
-
分片键相同：例如 order 和 order_item 的分片列都为
order_id，不能一个用order_id，另一个用user_id -
分片算法一致：包括类名、参数（如
sharding-count: 4）、哈希/范围逻辑完全相同。建议复用同一算法 Bean 或配置引用 -
真实数据节点拓扑一致：两张表的
actual-data-nodes必须映射到相同的库+表组合，例如都为ds${0..3}.t_order_${0..3}，不能 order 在 ds0~ds3，order_item 却分散在 ds0~ds7
配置示例（YAML）：
rules:
- !SHARDING
tables:
t_order:
actualDataNodes: ds${0..3}.t_order_${0..3}
tableStrategy:
standard:
shardingColumn: order_id
shardingAlgorithmName: t_order_inline
t_order_item:
actualDataNodes: ds${0..3}.t_order_item_${0..3}
tableStrategy:
standard:
shardingColumn: order_id
shardingAlgorithmName: t_order_inline # 复用同一算法
bindingTables:
- t_order,t_order_item
shardingAlgorithms:
t_order_inline:
type: INLINE
props:
algorithm-expression: t_order_${order_id % 4}
JOIN 路由优化效果：从广播到精准下推
启用 binding table 后，ShardingSphere 对符合绑定关系的 JOIN 可做深度优化：
- SQL：
SELECT * FROM t_order o JOIN t_order_item i ON o.order_id = i.order_id WHERE o.order_id = 12345 - 未配置 binding table：识别为非绑定 JOIN，触发 广播路由 —— 查询下发到全部 16 个真实表（4库×4表），再内存归并结果，耗时高、内存压力大
- 配置 binding table 且条件命中分片键：基于
order_id = 12345计算出唯一目标节点（如ds1.t_order_1和ds1.t_order_item_1），生成 单节点 JOIN 语句 直接下发，毫秒级响应 - 即使无分片键 WHERE 条件（如
WHERE o.status = 'paid'），只要两表绑定且分片策略一致，ShardingSphere 也能保证 相同分片键值的数据必然落在同一节点，从而将 JOIN 下推到每个分片内局部执行，避免跨节点数据拉取
验证与排障：确认 binding 是否生效
不要仅依赖配置存在，务必实测验证：
- 开启
sql-show: true，观察日志中实际执行的 SQL 和 target data source。若看到多节点广播（如同时出现ds0.t_order_0和ds2.t_order_item_2），说明 binding 未生效 - 检查
actual-data-nodes是否真的一致：用SHOW SHARDING TABLE RULES（Proxy）或 API 查看运行时规则，比对两张表的节点列表字符串是否完全相等 - 确认分片键在 JOIN ON 条件中是否被准确提取：ShardingSphere 仅识别形如
ON a.x = b.x的等值关联，不支持ON a.x = b.y + 1或函数包裹 - 注意 MyBatis 等框架可能因别名或动态 SQL 导致解析失败，建议先用原生 JDBC 执行简单 JOIN 测试基础路由
