窗口函数多分区扫描导致性能下降：当多个OVER()的PARTITION BY或ORDER BY不一致时，PostgreSQL和SQL Server会分别扫描多次；MySQL 8.0+单表有优化但JOIN后失效；带帧排序及PARTITION BY NULL更易引发全表扫描与内存压力。
多个窗口函数触发多次分区扫描
当一个查询里出现多个 OVER()，且它们的 PARTITION BY 或 ORDER BY 不一致时，数据库优化器往往无法复用中间结果。比如：
SUM(sales) OVER (PARTITION BY region)AVG(sales) OVER (PARTITION BY sales_rep)ROW_NUMBER() OVER (PARTITION BY region ORDER BY date)
这三者分区维度不同、排序需求也不同，PostgreSQL 和 SQL Server 通常会为每个窗口单独做一次分组+排序扫描——相当于对同一张表扫了三次。MySQL 8.0+ 对单表同源数据有合并优化，但一旦涉及 JOIN 后的宽表，这种优化基本失效。
ORDER BY + ROWS/RANGE 帧带来额外排序开销
OVER(PARTITION BY x ORDER BY y) 要求先按 y 排序再计算，而 GROUP BY 只需哈希分桶或简单排序（如用于 ORDER BY 输出）。更麻烦的是带帧的写法：
-
SUM(sales) OVER (ORDER BY date ROWS BETWEEN 6 PRECEDING AND CURRENT ROW)—— 强制全量排序，且每行都要定位“前6行”，CPU 和内存压力陡增 - 若
date列高基数（如毫秒级时间戳），RANGE还可能因值唯一导致等效于ROWS，但语义上仍走逻辑区间判断路径，慢得更隐蔽
相比之下，GROUP BY 的排序只发生在必要阶段（如 ORDER BY 输出或哈希冲突处理），不默认绑定到聚合逻辑里。
PARTITION BY NULL 处理引发隐式全表扫描
PARTITION BY col 遇到大量 NULL 值时，多数引擎会把所有 NULL 归为一个分区。如果该列本就稀疏（比如 referral_code 字段 95% 是 NULL），这个“大分区”就会拖慢整个窗口计算——因为引擎必须把几乎全表的数据拉进内存做局部排序或累计。而 GROUP BY col 在哈希阶段就能快速跳过空值桶，甚至通过索引规避扫描。
更易被忽略的一点：GROUP BY 可以用覆盖索引加速（如 INDEX(dept_id, salary) 支持 SELECT dept_id, AVG(salary) GROUP BY dept_id），但窗口函数几乎无法利用这类索引，尤其带 ORDER BY 时，基本依赖排序缓冲区或临时文件。
