SQL窗口函数OVER与GROUP BY区别_分析查询性能与适用场景

5次阅读

OVER 不能替代 GROUP BY，因二者作用层级不同：GROUP BY 聚合归并行集（输出行数≤输入），OVER 保留原始行结构叠加计算（输出行数 = 输入）；需压缩行数用 GROUP BY，需每行附加统计值才用 OVER。

SQL 窗口函数 OVER 与 GROUP BY 区别_分析查询性能与适用场景

GROUP BY 是对行集做聚合归并，输出结果行数 ≤ 输入行数；OVER 是在保留原始行结构基础上叠加计算，输出行数 = 输入行数。如果你需要把 100 行压缩成 10 行统计结果，GROUP BY 是唯一正解；如果要在每行上显示“当前用户订单总额”或“部门平均薪资”，才轮到 OVER 出场。

常见错误现象：SELECT user_id, SUM(amount) OVER(PARTITION BY user_id), COUNT(*) FROM orders —— 这里 COUNT(*) 没加窗口定义，会报错或返回全表计数，不是每个用户的订单数。

聚合函数在 OVER 中必须显式声明窗口（PARTITION BY / ORDER BY），否则默认是整个结果集
GROUP BY 后所有非聚合字段必须出现在 GROUP BY 列表中；而 OVER 可以和任意字段共存，不破坏原始行粒度
混合使用时注意逻辑顺序：SQL 执行顺序是 FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY，OVER 在 SELECT 阶段计算，所以看不到 WHERE 之后被过滤掉的行，但能看到 GROUP BY 后的聚合结果（只要没用 GROUP BY 掩盖原始行）

GROUP BY 一般需要哈希构建或排序，中间结果不可复用；OVER 看似轻量，但多个不同 PARTITION BY 或 ORDER BY 的窗口函数可能让优化器为同一数据集执行多次分组 / 排序——尤其是 PostgreSQL 和 SQL Server 中较明显。

使用场景提示：查“每个销售员当月销售额 + 全公司销售额占比 + 同岗位平均值”，三个指标分别依赖不同分区（PARTITION BY sales_id、PARTITION BY 1、PARTITION BY role），此时引擎大概率会扫描三次基础数据。

MySQL 8.0+ 对单表多窗口有合并优化，但跨表 JOIN 后的窗口仍易退化
避免在 OVER(ORDER BY …… ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) 中对高基数列排序，会导致大量临时排序开销
如果只需要全局统计（如总金额、最大值），直接用 SUM(amount) OVER() 比 (SELECT SUM(amount) FROM t) 子查询更高效，且无需关联

PARTITION BY col 默认把 NULL 当作一个独立分区；而 ORDER BY col 在窗口中默认把 NULL 排在最前（PostgreSQL）或最后（MySQL），且无法用 NULLS FIRST/LAST 统一控制（MySQL 不支持该语法）。

容易踩的坑：ROW_NUMBER() OVER(PARTITION BY category ORDER BY score DESC) 中，若 score 有 NULL，它们会被集中排在顶部或底部，导致排名跳变，且不同数据库行为不一致。