窗口函数替代 GROUP BY 的核心判断
先说一个核心判断：窗口函数确实能替代 GROUP BY，但有个关键前提——只有当你的需求是“既要保留每一行原始数据，又要同时叠加一个分组聚合值”时，这个替代才算得上真正合适。
举个例子就明白了。你想查询每个订单的详细信息，同时还要知道这个订单所属用户的历史总消费额。用窗口函数 SUM(amount) OVER (PARTITION BY user_id)，一行代码就能搞定，原始订单数据一行不少。但如果你只是想要一份简洁的用户总消费额列表，那么 GROUP BY user_id 依然是更轻量、更直接的选择。工具没有好坏，只有合不合适。
为什么 PARTITION BY 不等于 GROUP BY
这里有个根本性的区别，千万别当成简单的语法糖：PARTITION BY 是逻辑分组，它只划定计算范围，不折叠行；而 GROUP BY 是物理分组，它会强制合并行。这直接决定了输出结果的模样。
- 用
GROUP BY查询部门平均薪资，结果可能只有寥寥几行（比如3个部门），原始的员工记录全都不见了。 - 换成
A VG(salary) OVER (PARTITION BY department)，结果行数还是100行（假设有100名员工），但每行都多出了一列“本部门平均薪资”。这样一来，每个人与部门平均水平的对比，立马一目了然。 - 需要警惕的是，如果漏写了
PARTITION BY只留个OVER ()，大多数数据库引擎会计算一个全局值，然后广播到每一行。这就相当于给每行加了个冗余的常量列，通常没什么实际意义。
ORDER BY 在 OVER 里不是可选，而是关键开关
在窗口函数里，ORDER BY 子句可不是个可有可无的选项，它是个关键的行为开关。没有它，像 ROW_NUMBER()、SUM() OVER (...)、LAG() 这些函数的行为就不可控了——问题不是“慢”，而是可能“错”。
ROW_NUMBER() OVER (PARTITION BY user_id)：如果不指定ORDER BY，数据库可能会按存储的物理顺序编号，多次执行的结果可能都不一样，像 PostgreSQL 这样的数据库甚至会直接报错。SUM(net_weight) OVER (PARTITION BY box_no)：这会返回整箱的总重量，并把这个值广播给箱内的每一行。SUM(net_weight) OVER (PARTITION BY box_no ORDER BY net_weight)：一旦加上ORDER BY，默认的窗口框架就变成了ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW。这意味着它计算的是“当前卷，以及所有比它轻的卷的重量之和”，结果完全不同。- 所以，排序字段必须有明确的业务含义，或者有稳定的索引支撑。比如
ORDER BY id，只有在id严格递增且能代表插入时间顺序时，才是安全的。
性能陷阱比语法更容易让人翻车
语法学会了，真正的挑战往往在性能。窗口函数不是银弹，如果 PARTITION BY 的字段区分度很低，同时又缺少合适的索引，查询速度完全可能从秒级跌到分钟级。
- 想象一个场景：
PARTITION BY category，而 category 只有 ‘A’、‘B’、‘C’ 三个值，但表里有上千万行数据。这时，数据库不得不把海量数据拉进内存进行排序，WindowAgg节点很容易成为性能瓶颈。 - 怎么看信号？执行
EXPLAIN ANALYZE后，如果看到Using filesort或者WindowAgg节点耗时占比极高，基本就中招了。 - 解决办法很直接：必须建立联合索引。比如对于
PARTITION BY category ORDER BY created_at，建一个(category, created_at)的索引就能有效加速。 - 还有一个常见的优化顺序：别在窗口计算之后再用
WHERE过滤。应该先WHERE status = 'active'缩小数据集，再套用窗口函数，否则就是白白为百万行无效数据做了计算。
最后提一个最容易被忽略的细节：窗口函数计算出的结果是一个表达式，不能直接用在 WHERE 或 HA VING 子句里进行过滤。比如，你想筛选出“箱重大于1000”的卷，得在外面套一层子查询，或者使用 CTE（公共表表达式）。这一点，和 GROUP BY 后直接用 HA VING 过滤聚合结果的做法，完全不同。
