ShardingSphere 中广播表（Broadcast Table）和绑定表（Binding Table）是解决跨分片关联查询性能问题的关键配置，正确使用能避免笛卡尔积、减少跨库 JOIN，提升分布式查询效率。下面以 ShardingSphere-JDBC 5.x 为例，给出清晰、可落地的配置规范与典型示例。
广播表：全局一致、无分片键、所有节点全量复制
适用于字典类、配置类、状态码表等数据量小、变更频次低、需与任意分片表 JOIN 的场景（如 sys_dict、region）。必须满足：
- 表结构在所有数据源中完全一致；
- 不配置分片规则（即不设
actual-data-nodes或table-strategy）； - 写操作需由应用或 ShardingSphere 自动同步到所有库（推荐由应用控制更新，或借助事件通知+幂等机制）。
配置示例（YAML）：
sharding:
broadcast-tables:
- sys_dict
- region此后，对 sys_dict 的 SELECT 会路由到全部数据源并合并结果；INSERT/UPDATE/DELETE 则在每个数据源上执行一次（ShardingSphere 自动广播）。注意：不建议对广播表执行分页或大结果集查询，易引发性能瓶颈。
绑定表：多表逻辑主从关系、分片键一致、JOIN 时精准路由
用于存在强关联且分片键值完全相同的表对（如 order 与 order_item，均按 user_id 分片）。配置后，ShardingSphere 能识别二者分片一致性，将 JOIN 下推至单个分片内执行，避免跨库笛卡尔积。
前提条件：
- 两表必须使用相同分片算法（含相同分片键、相同分片策略）；
- 分片键取值严格一一对应（例如
order.user_id = order_item.user_id）； - 绑定关系需显式声明，否则仍按默认广播式 JOIN 处理。
配置示例（YAML）：
sharding:
tables:
t_order:
actual-data-nodes: ds${0..1}.t_order_${0..1}
table-strategy:
standard:
sharding-column: user_id
sharding-algorithm-name: user-id-mod
t_order_item:
actual-data-nodes: ds${0..1}.t_order_item_${0..1}
table-strategy:
standard:
sharding-column: user_id
sharding-algorithm-name: user-id-mod
binding-tables:
- t_order,t_order_item此时执行 SELECT * FROM t_order o JOIN t_order_item i ON o.user_id = i.user_id WHERE o.user_id = 123，ShardingSphere 会精准路由到同一数据源的同一组真实表（如 ds0.t_order_1 和 ds0.t_order_item_1），不产生跨库 JOIN。
广播表 + 绑定表组合使用：常见于多维关联场景
例如：订单（t_order）、订单项（t_order_item）、商品（t_product）、地区（t_region）。其中：
-
t_order与t_order_item是绑定表（共用user_id）； -
t_region是广播表（全库复制，供多处 JOIN）； -
t_product若按product_id分片，则不能与t_order直接绑定（分片键不同），需通过冗余字段或应用层拆解处理。
此时 SQL：SELECT o.*, i.*, r.name FROM t_order o JOIN t_order_item i ON o.user_id=i.user_id JOIN t_region r ON o.region_id=r.id WHERE o.user_id=123，ShardingSphere 可保证 o+i 在单库执行，再与广播表 r 做本地 JOIN，整体仍为单节点执行，高效可靠。
避坑提醒：配置生效的关键细节
以下情况会导致广播/绑定失效，务必检查：
- SQL 中 JOIN 条件未严格使用绑定列（如写成
o.user_id = i.user_id + 0或隐式类型转换）； - 广播表在某个数据源缺失或结构不一致（建表语句未同步）；
- 绑定表的分片算法配置不一致（如一个用
mod，另一个用hash）； - 使用了不支持的语法（如子查询中引用绑定表、UNION ALL 后 JOIN 广播表）；
- ShardingSphere 版本低于 5.1.0 时，对复杂绑定关系（如三表绑定）支持有限，建议升级或简化模型。
配置完成后，可通过 props.sql-show: true 开启 SQL 日志，观察实际路由目标，验证是否达到“单库执行”预期。
