OVER不会改变行数，因其在保留原始每行基础上附加计算结果；行数减少实际源于混用GROUP BY或误写聚合函数未加OVER/未写GROUP BY导致报错或语义错误。
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就会出错
GROUP BY 才真正压缩行数，OVER 只叠加计算
GROUP BY 是 SQL 执行逻辑中早于 SELECT 的阶段，它先把数据按指定列分组、归并，每组只保留一行结果；而 OVER 是在 SELECT 阶段执行的，此时原始行结构还在，只是多算几个值塞进去。
使用场景对比：
- 要统计“每个部门平均薪资”，用
SELECT dept, AVG(salary) FROM emp GROUP BY dept→ 输出行数 = 部门数 - 要查“每个员工薪资，以及他所在部门的平均薪资”，用
SELECT name, salary, AVG(salary) OVER(PARTITION BY dept)→ 输出行数 = 员工数 - 想同时看“个人薪资 + 全公司平均薪资 + 部门平均薪资”，三个指标可以共存于同一行，只要都用
OVER定义好分区即可
为什么有人觉得“加了 OVER 行数变了”？
典型诱因是写错了语法，比如：
- 在
GROUP BY查询里漏写了OVER，却误以为是它导致聚合 —— 实际是GROUP BY在起作用 - 把
ROW_NUMBER() OVER(...)和DISTINCT混用，结果发现去重失效，误判为OVER干扰了逻辑顺序（其实是ROW_NUMBER()在DISTINCT之前执行） - 用
LAG()或LEAD()时，发现某些行返回NULL，误以为“丢了数据”，其实只是窗口边界外无值，这是设计行为，不是丢行
最容易被忽略的执行顺序陷阱
OVER 在 SELECT 阶段计算，所以它能看到 WHERE 过滤后的行、也能看到 GROUP BY 后的聚合结果（前提是没破坏原始粒度）。但注意：
-
WHERE过滤发生在GROUP BY之前，所以OVER看不到被WHERE删掉的行 - 如果先
GROUP BY，再在SELECT里写SUM(x) OVER()，那这个SUM是对聚合后的结果集算的，不是原始明细 -
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 只负责“贴标签”，不负责“收摊子”。
