分组排名性能慢的核心原因是执行计划未并行化，常见于PARTITION BY为常量、数据未按分组键分布、并行参数配置不足或隐式串行陷阱（如函数加工分区字段）。
分组排名（ROW_NUMBER() / RANK() 等）性能慢，核心问题往往不是函数本身，而是执行计划没走并行，或被强制串行化。 尤其在大数据量、多分区场景下，单线程扫完再排序分组，耗时直接指数级上升。
为什么 ROW_NUMBER() OVER (PARTITION BY x ORDER BY y) 会变慢
窗口函数逻辑上需要先按 PARTITION BY 分组，再在每组内按 ORDER BY 排序并编号。数据库若无法将“分组 + 组内排序”拆到多个 worker 并行处理，就会退化成单节点全量扫描 + 内存排序 —— 这正是慢的根源。
常见触发串行化的条件包括：
-
PARTITION BY字段是常量（如PARTITION BY 1），导致整个结果集被压进一个 partition，优化器直接放弃并行 - 上游数据未按
PARTITION BY列做分布（例如 MaxCompute 中未DISTRIBUTE BY x），后续窗口计算被迫重分布或单点聚合 - PostgreSQL 中
max_parallel_workers_per_gather仍为默认值 2，且parallel_setup_cost太高，优化器判定“不值得并行” - SQL Server 的
MAXDOP被设为 1，或查询提示里写了OPTION (MAXDOP 1)
MaxCompute 中分组排名提速的关键操作
MaxCompute 默认对窗口函数支持并行，但实际是否启用，取决于输入数据的物理分布和参数控制。
必须检查并调整以下三点：
- 确认
PARTITION BY列不是常量或低基数字段；若业务确实需全局排名（无分组），改用ROW_NUMBER() OVER (ORDER BY y)，并确保y列有索引或已预排序 - 显式加
DISTRIBUTE BY x（x 即PARTITION BY字段），让数据在 map 阶段就按分组键打散，避免 reduce 阶段单点瓶颈 - 调大
odps.sql.mapper.split.size（如设为512），减少 instance 数量但提升单个 instance 处理量，避免因 instance 过多导致排队和初始化开销反超收益
示例写法：
SELECT key, value, ROW_NUMBER() OVER (PARTITION BY key ORDER BY value DESC) AS rn FROM src DISTRIBUTE BY key;
PostgreSQL 并行窗口函数的硬性开关
PG 10+ 支持并行窗口函数，但默认关闭部分路径。仅靠提高 max_parallel_workers_per_gather 不够，还必须打开几个关键配置：
-
max_parallel_workers_per_gather = 4（或更高，根据 CPU 核数留 1–2 核给 coordinator） -
parallel_setup_cost = 0.005、parallel_tuple_cost = 0.001：大幅降低并行启动门槛，否则小表也倾向单线程 -
enable_parallel_tuplestore = on（PG 14+ 必须开启）：否则带ORDER BY的窗口函数即使能并行，也会因 tuplestore 不支持而 fallback 到单线程
验证是否生效：用 EXPLAIN (ANALYZE, BUFFERS) 查看执行计划中是否有 Gather Merge 或 Parallel Seq Scan 节点，且 Workers Launched > 0。
容易被忽略的隐式串行陷阱
即使你调了所有并行参数，以下写法仍会让整个窗口计算降级为串行：
- 在
OVER子句里用了函数，如PARTITION BY date_trunc('day', ts)—— 若该表达式无法下推到 scan 阶段做分布，就会在 window node 里集中计算 - 外层嵌套了
ORDER BY全局排序（非窗口内排序），且未指定LIMIT，导致优化器放弃并行路径 - 窗口函数与其他强序列依赖操作混用，比如和
LAG()+ 多层子查询嵌套，使 planner 无法拆解并行边界
最稳妥的做法：把 PARTITION BY 和 ORDER BY 字段都保持为原始列（不加工）、建好索引，并确保它们出现在上游 WHERE 过滤后仍有足够基数。
