多个PARTITION BY会触发独立Shuffle阶段，因每个窗口函数调用对应单独的Shuffle，即使分区键相同也不保证物理复用；仅当分区键、排序键和窗口框架三者完全一致时，Spark 3.4+等引擎才可能合并为一次Shuffle。
多个PARTITION BY会触发独立Shuffle阶段
因为每个 PARTITION BY 子句对应一个窗口函数调用，而 Spark SQL（以及大多数 MPP 引擎如 Doris、Trino）在执行时，会为每个窗口函数单独规划一个 Shuffle 阶段。这不是“复用分区”，而是“各自重分区”——哪怕你两次都写 PARTITION BY user_id，只要它们属于不同窗口函数，引擎仍可能生成两个独立的 Shuffle。
- Spark 中，
ROW_NUMBER() OVER (PARTITION BY a)和SUM(x) OVER (PARTITION BY a ORDER BY b)会被拆成两个不同的 WindowOperator，各自走一遍Exchange（即 Shuffle） - Doris 的 MPP 执行计划里，每个
OVER子句都会生成独立的 Fragment，BE 节点间需按各自分区键重新分发数据 - 即使分区键完全相同，也**不保证物理分区复用**：优化器默认不合并窗口，除非开启特定规则（如 Spark 3.4+ 的
spark.sql.optimizer.windowExecution，但默认关闭）
常见错误现象：看起来没写错，却慢得离谱
你可能写了这样一段 SQL：
SELECT user_id, event_time, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY event_time) AS rn, COUNT(*) OVER (PARTITION BY user_id) AS cnt, AVG(amount) OVER (PARTITION BY user_id ORDER BY event_time ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS cum_avg FROM events;
表面看都是 PARTITION BY user_id，但实际会触发**至少三次 Shuffle**（取决于窗口类型和排序需求）。尤其当 user_id 基数高、数据量大时，三次小块数据重分布 + 排序开销叠加，远超一次 Shuffle + 多个窗口计算。
- 第一次 Shuffle：为
ROW_NUMBER()做按user_id分区 + 按event_time排序 - 第二次 Shuffle：为
COUNT(*)做纯哈希分区（无需排序），但仍是独立 Exchange - 第三次 Shuffle：为累计平均做 RANGE 窗口，需保留排序后状态，常触发额外 sort-merge
如何避免？关键看执行计划和窗口共性
不是所有多窗口都必须拆开 Shuffle。能否合并，取决于三个条件是否一致：分区键（PARTITION BY）、排序键（ORDER BY）、窗口框架（ROWS/RANGE）。只有三者完全相同时，现代引擎才可能复用分区。
- 能合并的例子：
ROW_NUMBER() OVER (PARTITION BY uid ORDER BY ts)和RANK() OVER (PARTITION BY uid ORDER BY ts)—— 可共用一次 Shuffle - 不能合并的例子：
MIN(x) OVER (PARTITION BY uid)和AVG(x) OVER (PARTITION BY uid ORDER BY ts)—— 排序要求不同，必然分离 - 实操建议：用
EXPLAIN EXTENDED或 Spark UI 的 DAG 图确认是否有多个Exchange节点；Doris 用户可查EXPLAIN输出中的WindowFunction条目数量
真正有效的优化路径：少定义、早聚合、分阶段
比起纠结“能不能合并窗口”，更可靠的做法是把逻辑从“全量窗口”转向“先分组再补序”。尤其当多个窗口都基于同一 PARTITION BY 且不需要实时排序时，GROUP BY 往往比窗口函数更轻量。
- 把
COUNT(*) OVER (PARTITION BY uid)改成GROUP BY uid+COUNT(*)，彻底消除该路 Shuffle - 对需要排序的场景（如排名），先用
GROUP BY+collect_list(struct(...))聚合成数组，再用高阶函数处理——避免跨节点排序 - 极端倾斜时，用加盐（salt）预分组：比如
PARTITION BY concat(uid, '_', floor(rand() * 10))，再二次聚合，比多个窗口硬扛更稳
窗口函数的便利性容易让人忽略它的物理代价。同一个 PARTITION BY 写三遍，不等于只 shuffle 一次；真正省资源的，从来不是写法“看起来一样”，而是执行时“确实走同一条数据通道”。
