嵌套查询本身不直接导致倾斜，但子查询结果作为Join或Group By驱动侧时，若输出key分布极不均匀，会在后续Shuffle阶段暴露严重倾斜；常见原因是忽略子查询对主查询key分布的隐式影响，如未过滤高频测试用户、维度表热点类目占比过高、LIMIT未加随机排序等；应通过加随机前缀“加盐”、显式控制key分布、启用Spark自适应倾斜优化、验证子查询key分布等方式治理。
嵌套查询本身不直接导致倾斜，但子查询结果作为Join或Group By的驱动侧时，若输出key分布极不均匀，就会在后续Shuffle阶段暴露出严重倾斜。
为什么子查询会放大倾斜？
常见错误是把子查询当成“中间表”直接使用，忽略了它对主查询key分布的隐式影响。比如：
- 子查询做了
GROUP BY user_id但未过滤掉高频测试用户（如user_id = '0'），导致主查询用该结果去JOIN大表时，所有匹配记录都打到同一个task - 子查询用了
SELECT DISTINCT category_id FROM dim_category，而维度表中'手机'类目占80%记录，结果集里这个key虽只出现一次，但Join后会膨胀成海量行 - 子查询带
LIMIT或TOP N却没加ORDER BY RAND()，实际取到的全是热点key
重分布子查询的关键操作：显式控制key分布
不是简单“加盐”，而是让子查询输出的每条记录都携带可打散的随机因子，并确保主查询能对齐处理：
- 子查询中对目标key加随机前缀：
CONCAT(FLOOR(RAND() * 5), '_', category_id)，并保留原始category_id字段 - 主查询
JOIN时，用新key关联，避免直接用原始key——否则仍走原哈希分区 - 最终聚合必须按原始key二次汇总，不能漏掉
GROUP BY category_id - 盐值范围建议设为
0~9：太小（如0~2）无法缓解强倾斜；太大（如0~100）会让小key也被拆分，增加Shuffle量
Spark SQL中启用自适应优化绕过手动改写
如果你用的是 Spark 3.0+，优先尝试开启内置倾斜检测，比手写加盐更稳妥：
- 设置
spark.sql.adaptive.enabled=true和spark.sql.adaptive.skewedJoin.enabled=true - 调大
spark.sql.adaptive.skewedPartitionMaxSplits到10（默认5，对强倾斜不够） - 注意：该机制只对
JOIN生效，GROUP BY倾斜仍需手动加盐 - 验证是否生效：查看执行计划中是否有
SkewJoin或AdaptiveSparkPlan标记
容易被忽略的陷阱：子查询缓存与统计信息失真
子查询如果被物化（如CTE加 MATERIALIZED 或临时表），它的统计信息可能滞后于源表更新：
- 执行前检查子查询输出的
COUNT(DISTINCT key)和COUNT(*)比值，若低于0.01，大概率存在倾斜风险 - Hive/Spark中对子查询结果表运行
ANALYZE TABLE，强制刷新统计信息 - 避免在子查询里用
WHERE dt = MAX(dt)这类非确定性表达式——可能导致每次执行计划不同，倾斜行为不稳定
真正卡住的往往不是怎么加盐，而是没确认子查询输出的key分布到底有多歪；跑一遍 SELECT key, COUNT(*) FROM (subquery) GROUP BY key ORDER BY COUNT(*) DESC LIMIT 5，比调十次参数都管用。
