嵌套查询中group by+子查询易放大倾斜，主因是内层未过滤导致高频key集中至外层reduce；coalesce等兜底值、null、多层join及窗口函数partition by倾斜均加剧该问题；深层嵌套还削弱优化器下推能力。
嵌套查询中 GROUP BY + 子查询容易放大倾斜
嵌套查询本身不直接导致倾斜，但当外层 GROUP BY 依赖内层子查询结果（尤其是未加过滤的聚合结果）时，内层输出可能生成大量重复或高频 Key，这些 Key 在外层再次分组时被集中调度到少数节点。比如：SELECT item_id, COUNT(*) FROM (SELECT item_id FROM orders WHERE dt = '2026-10-13') t GROUP BY item_id——如果当天某爆款商品占订单量 40%，这个 Key 就会把全部匹配记录塞进同一个 Reduce。
常见错误现象：执行计划里出现两层 Shuffle，第二层的输入数据量远超第一层；EXPLAIN 显示外层 HashAggregate 的 key 分布极不均匀；任务日志中反复出现 “Shuffle write: X GB” 且集中在 1–2 个 task。
- 内层子查询若未做
WHERE过滤或LIMIT控制，极易暴露出原始数据的天然倾斜 - 子查询返回字段若含低基数列（如
status、region），外层GROUP BY会继承并固化该倾斜 - Doris/StarRocks 等引擎对嵌套查询的谓词下推支持有限，部分条件无法下推到扫描阶段，导致无效数据提前进入 Shuffle
JOIN 嵌套 + NULL 或默认值引发隐式倾斜
多层嵌套常伴随多次 JOIN，而每层 JOIN 的 ON 条件若包含 NULL、空字符串或业务默认值（如 'unknown'），就会在 Hash 分区时全部落到同一 bucket。例如：SELECT * FROM (SELECT user_id, COALESCE(src_channel, 'unknown') ch FROM logs) a JOIN dim_channel b ON a.ch = b.channel_code——所有 'unknown' 都被哈希到同一个分区，后续无论嵌套几层，这个热点都持续存在。
使用场景：用户行为日志补维、跨系统 ID 映射、缺失值填充后的关联分析。
-
COALESCE、IFNULL、CASE WHEN生成的统一兜底值是隐形倾斜源，比业务热点更难察觉 - 嵌套越深，这类值经过多次 JOIN 后被复制放大的概率越高
- 部分引擎（如 Doris 2.0+）对
NULL做了特殊 Hash 处理，但自定义兜底值仍按普通字符串处理，必须手动规避
窗口函数嵌套导致 Shuffle 膨胀不可控
在嵌套查询中叠加 ROW_NUMBER() OVER (PARTITION BY x ORDER BY y) 或 RANK() 时，PARTITION BY 字段一旦存在倾斜 Key，整个窗口计算就会卡死在一个节点。更危险的是，如果外层再对该结果做 GROUP BY 或 JOIN，窗口输出的中间数据量可能比原始表大数倍（因排序和编号需全量缓存），进一步加剧 Shuffle 压力。
典型表现：EXPLAIN 中出现 WindowFunction 节点后紧跟 HashAggregate，且前者估算行数远高于源表；任务内存使用曲线陡升后突然 OOM。
- 窗口函数的
PARTITION BY必须和底层数据分布强相关，不能假设“业务上合理”就等于“物理上均匀” - 避免在嵌套子查询中直接使用高基数但实际低分布度的字段（如用
user_id分区，但 90% 行来自测试账号池） - 如必须用，优先在子查询最内层加采样或预过滤，例如先
WHERE user_id NOT IN (SELECT test_id FROM test_users)
嵌套层级过深削弱优化器下推能力
大多数分布式 SQL 引擎（Doris、Trino、Spark SQL）的优化器对嵌套深度有实际限制。超过 3–4 层后，谓词下推、Join 重排序、常量折叠等关键优化大概率失效，导致本可在扫描阶段过滤的数据被迫全量参与后续计算。这不直接造成倾斜，但让原本可规避的倾斜 Key 全部暴露出来。
性能影响：逻辑相同、仅嵌套层数不同的两条 SQL，执行时间可能相差 5–10 倍；EXPLAIN 显示中间节点无 Filter 下推标记，ScanNode 输出行数与原始表一致。
- 不要为了“语义清晰”强行拆成多层子查询；能写成单层
WITH的，别用SELECT FROM (SELECT FROM (...)) - Doris 中
CTE默认不物化，但嵌套过深仍会干扰代价估算，建议用WITH显式命名中间结果并加注释 - 遇到必须嵌套的场景（如递归查询），优先确认目标引擎是否支持
RECURSIVE WITH及其倾斜控制参数（如 Doris 的max_recursive_depth）
嵌套查询的倾斜风险不在语法本身，而在它天然掩盖了数据分布的真实形态——你看到的是逻辑结构，引擎执行时面对的是物理分布。最容易被忽略的，是那些看似无害的兜底值、测试账号、空字段，它们在层层嵌套中不断累积、复制、放大，最终在最后一层 GROUP BY 或 JOIN 上彻底爆发。
