窗口函数不压缩行数，GROUP BY 必然压缩：前者输出行数等于原表，后者等于分组键去重数；窗口函数可自由混用原始字段与聚合值，GROUP BY 要求非分组字段必须聚合；ORDER BY 与帧仅属窗口函数；执行时机、NULL 处理及性能影响亦不同。
窗口函数不压缩行数，GROUP BY 必然压缩
这是最直接、最不可绕开的区别：执行 SUM(sales) OVER (PARTITION BY region)，输出行数严格等于原始表行数；而 SUM(sales) GROUP BY region 的结果行数 = 去重后的 region 数量，通常远少于原表。
常见误判场景：
- 想在订单明细表里加一列「客户总消费额」，却写了
SELECT order_id, customer_id, SUM(amount) FROM orders GROUP BY customer_id→ 报错或只返回几行，订单明细全丢了 - 正确做法是去掉
GROUP BY，直接写SUM(amount) OVER (PARTITION BY customer_id)，每行都带对应客户的总消费
能否混用原始字段和聚合值
GROUP BY 后的 SELECT 列必须满足：要么是分组键（如 customer_id），要么是聚合表达式（如 SUM(amount)）。任何未被聚合的原始字段（比如 order_date、product_name）直接写进去就会报错：column "order_date" must appear in the GROUP BY clause。
窗口函数没有这限制：
-
SELECT order_id, customer_id, order_date, product_name, SUM(amount) OVER (PARTITION BY customer_id)完全合法 - 所有原始字段照常出现，同时每行附加一个计算列，语义清晰、无需
JOIN或子查询
ORDER BY 和帧（ROWS/RANGE）只属于窗口函数
GROUP BY 不支持排序上下文，更不支持“从上一行到当前行”这类动态范围。而 OVER 子句中的 ORDER BY 不仅决定排序，还隐式影响默认帧行为：
-
SUM(sales) OVER (PARTITION BY region ORDER BY date)默认按RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW（某些数据库），遇到相同date会把同天所有行都计入累计和 -
SUM(sales) OVER (PARTITION BY region ORDER BY date ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)才真正实现“逐行累加”，物理行偏移可控 -
LAG(sales, 1) OVER (PARTITION BY customer_id ORDER BY order_date)这类跨行取值，GROUP BY根本无法表达
执行时机和 NULL 处理逻辑不同
窗口函数在 SELECT 阶段最后执行，能看到 WHERE 过滤后、甚至 GROUP BY 聚合后的中间结果；而 GROUP BY 发生在 WHERE 之后、HAVING 之前，是行压缩层。
NULL 行为也不同：
-
COUNT(col) GROUP BY x和COUNT(col) OVER (PARTITION BY x)都跳过NULL，但前者返回单值，后者每行返回同一分区内的非空计数 -
ROWS BETWEEN帧中，NULL值仍占位置，但参与聚合时被忽略 → 实际有效行数可能浮动，分母不等于帧声明长度 -
PARTITION BY col把NULL当作独立分区；ORDER BY col在窗口中对NULL的排序位置因数据库而异（PostgreSQL 默认在前，MySQL 默认在后），且NULLS FIRST/LAST并非全平台支持
真正容易被忽略的是：同一个查询里混用多个不同 PARTITION BY 或 ORDER BY 的窗口函数，可能导致引擎重复扫描基础数据——尤其在 PostgreSQL 或 SQL Server 中，性能退化比想象中更早出现。别只看语法漂亮，得盯执行计划。
