跨库 join 应尽量避免，因其需跨网络、事务和节点协调，主流中间件仅支持广播join或应用层拼接，性能损耗大；广播join适用于读多写少、数据量极小的字典表。
跨库 JOIN 和全局表是 sql 分片（Sharding）中绕不开的两个关键设计点，它们本质上是在一致性、性能、可维护性之间做取舍。没有银弹方案，只有根据业务读写特征、数据规模和变更频率做出的务实选择。
跨库 JOIN：能避免就尽量避免
分库后，原本单库内的 JOIN 操作会变成跨网络、跨事务、跨节点的复杂协调过程。主流分库中间件（如 ShardingSphere、MyCat）对跨库 JOIN 的支持有限，多数仅支持“广播 JOIN”或“嵌套循环 + 应用层拼接”，性能损耗显著。
- 广播 JOIN：将小表（如字典表）全量拉到每个分片执行本地 JOIN，适合读多写少、数据量极小（
- 应用层 JOIN：先查主表获取分片键，再按需并发查询关联分片，最后在内存中合并。逻辑清晰但开发成本高，且易因网络抖动或超时导致结果不完整
- 禁止强一致 JOIN：跨分片无法保证 ACID，尤其涉及写操作时，两阶段提交（2PC）在 MySQL 生态中基本不可用，延迟与失败率高
全局表（Broadcast Table）：适用场景明确，但有隐性代价
全局表指在所有分片中完全一致、只读或低频更新的维表（如省市区、币种、订单状态码）。它通过自动同步机制解决跨库 JOIN 需求，但不是“万能缓存”。
- 必须满足“读远大于写”：每次更新需同步至全部分片，N 个分片即 N 次写入，写放大明显；若日均更新超百次，同步延迟与失败风险上升
- 数据体积要小：单行不宜超 1KB，总行数建议控制在 5 万以内；否则加载慢、内存占用高、影响分片路由性能
- 不能有分片键依赖：全局表本身不分片，其字段不可作为其他表的分片键来源（例如不能用“省编码”作为用户表分片依据，否则破坏分片逻辑）
更推荐的替代路径：冗余+异步+最终一致
比起强依赖跨库 JOIN 或全局表，多数高可用系统倾向用空间换时间、用异步换强一致：
- 字段冗余：在订单表中直接冗余“省份名称”“币种符号”，避免实时 JOIN；配合定时任务或 CDC 同步源表变更
- 宽表预计算：使用离线/实时数仓生成带维度信息的宽表（如订单+用户+地址），供查询服务直取
- 引用 ID + 异步补全：接口返回订单 ID 和 province_id，前端或网关异步调用维表服务补全展示字段；对一致性要求不高的场景足够可靠
决策 checklist：选哪个？
面对一个待关联的维表，快速判断方式：
- 该表是否几乎只读？→ 是 → 考虑全局表
- 该表单次更新是否影响 ≤3 个分片？→ 否 → 全局表同步压力过大，改用冗余或异步
- 业务能否接受 5 秒内维度数据不一致？→ 是 → 优先异步补全或定时同步
- JOIN 结果是否用于核心交易（如库存扣减校验）？→ 是 → 必须拆到同一分片内，或改用分布式事务框架（如 Seata AT 模式），而非跨库 JOIN
不复杂但容易忽略：真正决定架构成败的，往往不是技术多炫酷，而是对“这个字段多久变一次”“用户真的需要立刻看到最新值吗”这类问题的诚实回答。