窗口函数中只要出现order by就必须全量排序，因需确定行间相对顺序；无order by时row_number()结果不可预测；仅partition by+聚合或接受无序编号可避免排序。
因为窗口函数中只要出现 ORDER BY 子句，Spark 就必须对每个分区内数据做全量排序，而排序操作天然需要 shuffle 和内存缓冲 —— 这就是“全局排序”感的来源，实际是分区内全局排序，不是跨分区。
ORDER BY 是窗口帧计算的前提
窗口函数要确定“当前行在哪、前面几行是哪些、后面几行是谁”，必须先知道所有行的相对顺序。比如 ROWS BETWEEN 2 PRECEDING AND CURRENT ROW 看似只取三行，但 Spark 无法跳过排序直接定位“前两行”，因为数据在 partition 内初始是乱序的。
- 没有
ORDER BY时，ROW_NUMBER()仍可运行，但结果不可预测（取决于 task 处理顺序） - 有
ORDER BY但没PARTITION BY，就变成对整个 dataset 排序，开销最大 - 即使只用
RANGE BETWEEN，也依赖排序后值的有序性才能快速界定范围
排序开销远超聚合，CPU 和 GC 压力明显
TPC-DS 测试显示：对 10 亿行按时间字段排序时，CPU 利用率常飙到 90%，GC pause 显著增长。这不是 bug，而是排序本身需要构建排序缓冲区、比较器调用、临时磁盘 spill 等固有成本。
- 默认
spark.sql.adaptive.enabled=true也无法绕过排序阶段 -
sort.merge.file.buffer.size和spark.sql.files.maxPartitionBytes会影响 spill 频率，但不减少排序必要性 - 如果业务只要“组内编号”，且能接受非确定顺序，可考虑去掉
ORDER BY+ 改用monotonically_increasing_id()模拟
真正能避免排序的场景极少
只有两类情况不触发排序：
- 纯
PARTITION BY+ 聚合函数（如SUM(col) OVER (PARTITION BY a)），此时 Spark 可复用 hash aggregate 的分组逻辑 - 使用
ROW_NUMBER() OVER (PARTITION BY a)且明确接受无序编号（文档称其行为“undefined”，实际由 partition 内 task 处理批次决定）
一旦你写了 ORDER BY，哪怕只是 ORDER BY id ASC，排序就必然发生 —— 不是 Spark 故意加戏，是语义强制要求。
最容易被忽略的是：很多用户以为 “我只取前 3 行”，所以期待 Spark 能用 top-k 优化，但窗口函数的 ORDER BY 是为整个窗口帧服务的，不是为单行裁剪设计的。真要 top-k，该用 rank() 或 row_number() + FILTER，而不是靠窗口帧收缩来省排序。
