ShuffleHashJoin并行度由spark.sql.shuffle.partitions决定，而非Join本身控制；其实际Task数等于Shuffle输出分区数，受该参数影响，且对数据倾斜敏感，调高分区数无法根治倾斜问题。
为什么 SHUFFLE HASH JOIN 的并行度不是直接可调的
Spark SQL 中没有 SHUFFLE_HASH_JOIN 这个显式算子名，它只是 Spark 在 AQE（自适应查询执行）或 Join 策略选择阶段内部决定的一种物理执行方式。你看到的 ShuffleHashJoin 出现在 Spark UI 的物理计划里，代表 Spark 决定用 Hash Join + Shuffle 的组合来执行，但它的并行度**不由 Join 本身控制**，而是由上游 Shuffle 分区数决定。
真正影响并行度的是 spark.sql.shuffle.partitions
这个参数决定了所有宽依赖操作（包括 Join、Group By、Distinct 等）产生的 Shuffle 输出分区数，也就是后续 Stage 中 Task 的数量。对 ShuffleHashJoin 来说：
- 如果左侧表被 shuffle 后分成了 200 个分区，右侧表也被 shuffle 成 200 个分区，那么 Join 阶段就会启动 200 个 Task 并行执行
- 默认值是
200，但在小数据量场景下会浪费资源，在大数据量 + 倾斜场景下又可能加剧单 Task 压力 - 建议设为集群总 CPU core 数的 2~3 倍（例如 100 cores → 设为
200或300），但需结合实际数据量观察 Task 执行时间分布
别碰 spark.sql.join.preferSortMergeJoin 来“强制”用 Hash Join
这个配置的作用是「降低 SortMergeJoin 的触发倾向」，但它不保证启用 Hash Join，更不会提升并行度。盲目设为 false 可能导致：
- 本该走 Broadcast Join 的小表被迫 shuffle，徒增开销
- 大表 Join 大表时，SortMergeJoin 实际更稳定，强行压制反而引发 OOM 或长尾
- 并行度依然由
spark.sql.shuffle.partitions控制，跟这个开关无关
当看到 ShuffleHashJoin 执行慢，优先检查倾斜而非调并行度
Hash Join 对数据分布敏感，一旦某 key 出现严重倾斜（比如 NULL、空字符串、热门 ID），会导致单个 Task 处理远超均值的数据量——此时加分区数只是把压力分散到更多 Task 上，但倾斜 key 还是集中在某几个 Task，效果有限。
- 先在 Join 前用
SELECT key, COUNT(*) FROM table GROUP BY key ORDER BY COUNT(*) DESC LIMIT 10查看 top key 分布 - 确认倾斜后，优先用
spark.sql.adaptive.skewJoin.enabled=true（需配合spark.sql.adaptive.enabled=true）让 AQE 自动拆分倾斜分区 - 若 AQE 不适用（如 Spark
并行度只是“分蛋糕”的刀数，蛋糕本身不均匀，切得再细也救不了那一块最大的。
