连接策略怎么被选中
同一个 join 在不同数据规模下有完全不同的最优执行方式：一侧数据很小时广播过去最省事，两侧都大时按 key 重分布才现实，两表分桶一致时还能省掉重分布。引擎的优化器根据统计信息和表结构做判断，判断依据错，选出的计划就会差出几倍。
基本信息
| 广播连接 | 小表复制到各节点，避免重分布 |
|---|---|
| 重分布连接 | 两侧按 key 打散，网络开销大 |
| 分桶对齐连接 | 桶数与连接键一致时可省去重分布 |
| 决策依据 | 统计信息、表大小、分桶与排序键 |
| 查看方式 | EXPLAIN 查看实际选用的策略 |
典型使用场景
- 事实表关小维表：广播维表最省开销
- 两张事实表互连：按 key 重分布，靠统计信息找较小的先传入
- 周期性固定关联：预先按连接键分桶，把重分布成本摊到建表阶段
- 存在超大 key：连接前先对倾斜键单独处理
- 计划异常排查：对比 EXPLAIN 中估算行数与实际行数，判断统计是否可信
查看执行计划
查看执行计划
-- 先在 EXPLAIN 里确认连接方式与估算行数
EXPLAIN
SELECT o.store_id, count(1) AS order_cnt
FROM dwd_trade_order_di o
JOIN dim_store s ON o.store_id = s.store_id
WHERE o.dt = '2026-10-12'
GROUP BY o.store_id;
-- 估算行数与实际差得多时，先补统计信息再谈调参策略对照
| 策略 | 适用条件 | 主要代价 |
|---|---|---|
| 广播连接 | 一侧远小于另一侧 | 每节点内存占用 |
| 重分布连接 | 两侧都大 | 网络传输与落盘 |
| 分桶对齐连接 | 两表桶数与键一致 | 建表结构约束 |
| 加盐分散 | 存在超大倾斜 key | 额外计算与代码复杂度 |
| 预先聚合 | 连接只为取汇总值 | 需要额外的汇总表 |
倾斜比策略更常见
实际链路里让 join 变慢的往往不是策略选错，而是某个 key 的数据量占到总量的一大半：无论广播还是重分布，这个 key 都落在一个节点上，其余节点早早跑完等着。识别方式是看各任务处理行数的分布，差出几个数量级就基本可以确认。处理手段包括单独拆出倾斜 key 再合并结果。
分桶对齐连接的效果依赖两侧桶数一致。任何一侧调整桶数都会让已建好的连接失效并退化为重分布，因此改桶数属于结构性变更，需要评估下游影响。
把广播阈值调大以解决单个慢任务，会让优化器把本不该广播的表也广播出去，执行节点内存压力上升，集群里其他任务跟着受影响。