SQL中OVER子句不改变数据行数,仅在每行附加计算结果;GROUPBY才是压缩行数的真正原因。常见误解源于混用GROUPBY与窗口函数,或未理解聚合函数在不同上下文中行为差异。
先明确一个核心判断:OVER 永远不会改变数据行数——它在原始每一行的基础上附加计算结果,行数不会少一行。
那为什么很多人踩坑后,总觉得“加了OVER,行数就变了”?
长期稳定更新的攒劲资源: >>>点此立即查看<<<
原因其实很直接:你看到的行数变化,不是 OVER 本身造成的,而是你混用了 GROUP BY 和窗口函数,或者误解了聚合函数在两种上下文中的行为。单独使用 SUM(amount) 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 是背锅侠——它老老实实在每行上贴标签,结果行数变化被算到了它头上。
理解 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 是“给每个人发奖状”,行数一个不少。
典型诱因是写错了语法:
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 只负责“贴标签”,不负责“收摊子”。
侠游戏发布此文仅为了传递信息,不代表侠游戏网站认同其观点或证实其描述