聚合函数后加OVER为何改变输出行数

彻底搞懂：为什么SQL聚合函数加OVER后，行数没变但你总感觉它变了

先明确一个核心判断：OVER 永远不会改变数据行数——它在原始每一行的基础上附加计算结果，行数不会少一行。

那为什么很多人踩坑后，总觉得“加了OVER，行数就变了”？

原因其实很直接：你看到的行数变化，不是 OVER 本身造成的，而是你混用了 GROUP BY 和窗口函数，或者误解了聚合函数在两种上下文中的行为。单独使用 SUM(amount) OVER()，输出行数一定等于输入行数——它只是给每一行都附上同一个总和值。

OVER 不会改变行数，但容易误以为它“改变了”

来看看常见踩坑现场：

• SELECT user_id, SUM(amount) OVER(PARTITION BY user_id) —— 这行本身不会减少行数。但如果前面加了 GROUP BY user_id，那才是行数变少的真正原因。
• SELECT user_id, SUM(amount)（没写 OVER，也没写 GROUP BY）—— 这条会直接报错，因为 MySQL/PostgreSQL 要求非聚合字段必须出现在 GROUP BY 中。
• 把 COUNT(*) 写成 COUNT(*) OVER() 是合法的，但写成 COUNT(*) 单独出现且无 GROUP BY 就会出错。

说白了，OVER 是背锅侠——它老老实实在每行上贴标签，结果行数变化被算到了它头上。

GROUP BY 才真正压缩行数，OVER 只叠加计算

理解 SQL 执行顺序，这个问题就迎刃而解了。GROUP BY 是 SQL 执行逻辑中早于 SELECT 的阶段，它先把数据按指定列分组、归并，每组只保留一行结果。而 OVER 是在 SELECT 阶段执行的，此时原始行结构还在，只是多算几个值塞进去。

场景对比一目了然：

• 要统计“每个部门平均薪资”，用 SELECT dept, A VG(salary) FROM emp GROUP BY dept → 输出行数 = 部门数。
• 要查“每个员工薪资，以及他所在部门的平均薪资”，用 SELECT name, salary, A VG(salary) OVER(PARTITION BY dept) → 输出行数 = 员工数。
• 想同时看“个人薪资 + 全公司平均薪资 + 部门平均薪资”，三个指标可以共存于同一行，只要都用 OVER 定义好分区即可。

关键在这里：GROUP BY 是“合并同类项”，行数必然减少；OVER 是“给每个人发奖状”，行数一个不少。

为什么有人觉得“加了 OVER 行数变了”？

典型诱因是写错了语法：

• 在 GROUP BY 查询里漏写了 OVER，却误以为是它导致聚合——实际是 GROUP BY 在起作用。
• 把 ROW_NUMBER() OVER(...) 和 DISTINCT 混用，结果发现去重失效，误判为 OVER 干扰了逻辑顺序（其实是 ROW_NUMBER() 在 DISTINCT 之前执行）。
• 用 LAG() 或 LEAD() 时，发现某些行返回 NULL，误以为“丢了数据”。其实只是窗口边界外无值，这是设计行为，不是丢行。

还有一个更容易中招的点：如果先 GROUP BY，再在 SELECT 里写 SUM(x) OVER()，那这个 SUM 是对聚合后的结果集算的，不是原始明细。这时行数虽然没变（相对于 GROUP BY 的结果），但计算粒度已经完全不同了。

最容易被忽略的执行顺序陷阱

OVER 在 SELECT 阶段计算，所以它能看到 WHERE 过滤后的行、也能看到 GROUP BY 后的聚合结果（前提是没破坏原始粒度）。但注意：

• WHERE 过滤发生在 GROUP BY 之前，所以 OVER 看不到被 WHERE 删掉的行。
• PARTITION BY col 中 col 为 NULL 时，MySQL 和 PostgreSQL 处理方式不一致：MySQL 把所有 NULL 归为一个分区，PostgreSQL 也如此，但排序时 ORDER BY col 对 NULL 的位置控制不可靠（MySQL 不支持 NULLS FIRST）。

复杂点在于：多个不同 PARTITION BY 的窗口函数可能触发多次扫描，尤其在 PostgreSQL 和 SQL Server 上；而 GROUP BY 虽重，但中间结果可复用。别指望靠加个 OVER 就绕过 GROUP BY 的语义约束——该分组还得分组，该聚合还得聚合，OVER 只负责“贴标签”，不负责“收摊子”。