根本区别在于行数处理：group by压缩多行成一行，丢失明细；窗口函数保留原始行数，在每行附加基于分区的计算值。
窗口函数和GROUP BY的根本区别在哪
GROUP BY 会压缩行数，把多行聚合成一行；而窗口函数（如 ROW_NUMBER()、SUM() OVER ()）是在保留原始行数的前提下，对每行计算一个基于窗口的聚合值。这不是“替代”，而是“不同用途”——想保留明细数据又需要聚合结果时，才用窗口函数。
常见误用场景：有人试图用 SUM(col) OVER () 替代 GROUP BY id; SUM(col) 来“去重+求和”，结果发现行数没变，还多出一堆重复的总和——这恰恰说明用对了，但也暴露了需求理解偏差。
关键判断点：你需要的结果集是否必须保持原始行结构？ 如果是，窗口函数是唯一选择；如果只要汇总统计，GROUP BY 更直接、更高效。
哪些聚合场景能用窗口函数“模拟”GROUP BY效果
不是所有 GROUP BY 场景都适合改写，但以下几类在保留明细的同时，能自然复现分组聚合语义：
- 计算每个分组的合计、均值、最大值等，并附在每行上 —— 用
SUM(col) OVER (PARTITION BY group_col) - 按分组排序后取 Top N（比如每部门薪资前3）—— 用
ROW_NUMBER() OVER (PARTITION BY dept ORDER BY salary DESC) - 计算累计值或移动平均（如“到当前行为止的销售总额”）—— 用
SUM(sales) OVER (ORDER BY date ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) - 对比本行与分组内均值的偏差（如“比本部门平均高多少”）—— 用
salary - AVG(salary) OVER (PARTITION BY dept)
注意：PARTITION BY 是窗口函数中对应 GROUP BY 的核心子句，但它不改变行数，也不过滤 NULL 分组键（GROUP BY 中 NULL 会自成一组，窗口函数也一样）。
容易踩的坑：ORDER BY 在窗口定义里的隐式影响
很多人写 COUNT(*) OVER (PARTITION BY user_id) 没问题，但一旦加上 ORDER BY event_time，行为就变了：
-
COUNT(*) OVER (PARTITION BY user_id ORDER BY event_time)默认变成“从第一行到当前行”的累积计数，不是全组总数 - 要得到真正的“每组总行数”，必须显式声明帧范围：
COUNT(*) OVER (PARTITION BY user_id ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) - MySQL 8.0+ 和 PostgreSQL 支持
ROWS/RANGE，但 SQLite 默认只认ROWS，且不支持UNBOUNDED FOLLOWING在某些旧版本中
另外，ORDER BY 在窗口中还会触发排序开销。如果只是要分组聚合值（不需要排序语义），却误加了 ORDER BY，性能可能陡降，尤其在大表上。
性能与可读性权衡：什么时候不该硬套窗口函数
窗口函数不是银弹。以下情况建议坚持用 GROUP BY：
- 只查聚合结果（如“各部门平均薪资”），不需要关联原始记录 ——
GROUP BY扫描一次、内存占用小、执行计划清晰 - 聚合字段上有索引，且
GROUP BY能走索引扫描，而窗口函数无法利用该索引（多数引擎对PARTITION BY字段的索引支持有限） - 需要
HAVING过滤分组 —— 窗口函数无法直接实现，得套子查询或 CTE，反而更绕 - 兼容老系统（如 MySQL 5.7 或 SQL Server 2008）—— 窗口函数根本不可用
真正需要窗口函数的时刻，往往出现在报表明细页：既要展示每笔订单，又要标出“该客户历史总消费”“该品类平均单价”“本月累计销量排名”。这些信息无法靠单层 GROUP BY 输出，强行 JOIN 多个聚合子查询又难维护。
细节决定成败：比如 PARTITION BY 列含 NULL 时，所有 NULL 值会被划入同一组；而有些业务逻辑要求 NULL 单独视为“未知组”，就得提前 COALESCE(group_col, '<strong>NULL</strong>') 处理——这个很容易被忽略。
