窗口函数不能替代GROUP BY，因二者作用层级不同：GROUP BY压缩行数（输出≤输入），OVER保留原始行结构叠加计算（输出=输入）；需压缩用GROUP BY，需每行附加统计值才用OVER。
GROUP BY 会删掉原始行，窗口函数只是加一列
想压缩数据、出汇总报表，必须用 GROUP BY；想保留每条明细记录，同时附带分组统计值（比如“每个员工的工资，以及他所在部门的平均工资”），只能用窗口函数。
常见错误现象：SELECT name, department, AVG(salary) FROM employees GROUP BY department —— MySQL 会报 ERROR 1055，PostgreSQL 直接拒绝执行。因为 name 既没出现在 GROUP BY 列表里，也没被聚合函数包裹，数据库无法确定该取哪一行的 name。
- 硬加
MAX(name)可能语法通过，但语义错位：返回的是部门里名字字典序最大的人，和平均薪资毫无业务关联 -
GROUP BY后所有非聚合字段必须严格属于分组键，否则就是逻辑漏洞 - 窗口函数没有这个限制：
SELECT name, department, salary, AVG(salary) OVER (PARTITION BY department)是完全合法且语义清晰的
需要排名、累计、跨行取值？只能用窗口函数
GROUP BY 做不了这些事，它只输出单个聚合值，不提供行间关系或顺序能力。
典型场景：
- 查每个用户的最新订单完整字段 → 必须用
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC)打标，再套一层子查询过滤rn = 1 - 计算“截至当前月的累计销售额” →
SUM(amount) OVER (PARTITION BY year ORDER BY month ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) - 取上一笔订单金额做环比 →
LAG(amount) OVER (PARTITION BY user_id ORDER BY created_at)
注意：WHERE 阶段看不到窗口函数结果，WHERE rn = 1 一定报错；必须写成 WITH ranked AS (...) SELECT * FROM ranked WHERE rn = 1。
PARTITION BY 不等于 GROUP BY，漏写就全算错了
PARTITION BY 定义的是计算范围，不是分组输出逻辑。漏写 PARTITION BY，AVG(salary) OVER () 就变成全表平均，每行都填同一个数，而不是按部门算。
ORDER BY 在窗口函数里不是可选的——尤其对 ROW_NUMBER()、RANK() 或累计类函数：
-
ROW_NUMBER() OVER (PARTITION BY dept)：MySQL 可能按物理存储顺序编号，多次执行结果不一致；PostgreSQL 直接报错 -
SUM(net_weight) OVER (PARTITION BY box_no ORDER BY weight)和不加ORDER BY的结果完全不同：前者是“比当前轻的所有卷之和”，后者是整箱总重 - 排序字段必须有业务稳定性，比如用
created_at比用id更可靠，除非你能保证id严格递增且代表时序
性能不是“窗口函数一定快”，多窗口可能触发多次扫描
表面看窗口函数不改行数，好像更轻量，但多个不同 PARTITION BY 或 ORDER BY 的窗口函数，会让优化器为同一张表反复做分组或排序。
例如：SUM(amount) OVER (PARTITION BY user_id)、AVG(amount) OVER (PARTITION BY role)、MAX(amount) OVER () 这三个并存，PostgreSQL 或 SQL Server 很可能扫描基础表三次。
- MySQL 8.0+ 对单表多窗口有合并优化，但一旦涉及
JOIN，优化容易退化 - 如果只需要全局值（如全表总金额），
SUM(amount) OVER ()比子查询(SELECT SUM(amount) FROM t)更高效，且不用关联 - 高基数列（如
user_id）上做ORDER BY+ 累计窗口，会产生大量临时排序开销，要谨慎
真正容易被忽略的是 NULL 处理差异：PARTITION BY col 把所有 NULL 当作一个独立分区；而 ORDER BY col 在窗口中默认把 NULL 排最前（PostgreSQL）或最后（MySQL），且不能用 NULLS FIRST 统一行为。
