开窗函数解决的是保留明细行并附加分组计算值的问题，而GROUP BY强制聚合压缩数据；SUM(amount) OVER (PARTITION BY customer_id)可一行实现“每订单显示客户总消费”，无需JOIN或子查询。
开窗函数不是GROUP BY的“升级版”，它解决的是完全不同的问题：你需要每行都保留，同时又想在每行上附带一个分组计算值——这时候OVER才是唯一自然的选择。
为什么不能直接用GROUP BY实现“明细+汇总”共存
GROUP BY强制压缩数据，输出行数必然 ≤ 输入行数。想查每个订单的同时显示该客户的总消费额？GROUP BY order_id会丢掉客户维度，GROUP BY customer_id又会丢掉订单明细。你得写子查询或JOIN才能拼回来，SQL变重、可读性下降、执行计划更难优化。
而SUM(amount) OVER (PARTITION BY customer_id)一行就搞定：原始订单行全在，每行多一列“这个客户总共花了多少钱”。没有JOIN，不增行也不减行，语义直白。
- 常见错误现象：
SELECT order_id, customer_id, amount, SUM(amount) FROM orders GROUP BY order_id—— 报错，因为customer_id和amount不在GROUP BY里，也不能直接选 - 使用场景：报表中既要展示单条记录，又要带上下文指标（如部门平均薪资、用户历史订单数、品类累计销量）
- 性能影响：GROUP BY后若还要JOIN回明细，可能触发笛卡尔积或多次扫描；开窗一次扫描即可
PARTITION BY 和 GROUP BY 的物理行为差异
PARTITION BY只是逻辑切片，数据库不会真正把数据按partition分组写入临时结构；它只是告诉聚合函数：“你在这一堆行里算，但别合并它们”。而GROUP BY必须物化分组结果，排序/哈希/去重一步都不能少。
这意味着：对千万级表按只有3个取值的status字段做PARTITION BY status，若没索引，窗口计算极易OOM或慢成瓶颈；但同样字段做GROUP BY status反而快——因为只产出3行，聚合过程极轻量。
- 容易踩的坑：
OVER (PARTITION BY category)却不加ORDER BY，对ROW_NUMBER()或SUM() OVER (ORDER BY ...)类函数，结果不可复现（PostgreSQL直接报错） - 参数差异：
PARTITION BY a, b等价于GROUP BY a,b的分组逻辑，但不等价于GROUP BY的执行路径 - 兼容性注意：MySQL 8.0+、PostgreSQL 8.4+、SQL Server 2005+支持；SQLite需3.25+且编译时开启窗口函数支持
ORDER BY 在 OVER 里的作用远不止“排序”
它决定窗口帧（frame）默认范围。没写ORDER BY时，SUM(x) OVER (PARTITION BY y)等价于SUM(x) OVER (PARTITION BY y ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING)——即整个分区求和；但加上ORDER BY z后，默认变成ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，也就是“到当前行为止的累计和”。
这个隐式帧规则是多数人调试出错的根源：你以为在算分区总和，实际在跑累计值；或者想用LAG()取上一行，却因ORDER BY字段无业务意义（比如用id但id有空缺或乱序），导致取错行。
- 使用场景：
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at)标用户第几笔订单；AVG(sales) OVER (PARTITION BY region ORDER BY month ROWS BETWEEN 2 PRECEDING AND CURRENT ROW)算近3个月滚动均值 - 关键判断：只要函数行为依赖顺序（
ROW_NUMBER、RANK、LAG、带ORDER BY的SUM），就必须明确ORDER BY字段且该字段应有稳定业务序（如时间戳、严格递增ID） - 容易踩的坑：在
OVER里写ORDER BY RAND()——结果随机，无法复现；或用ORDER BY updated_at但该字段大量重复，导致RANK()并列过多且顺序不确定
WHERE 过滤必须放在开窗之前
窗口函数在SQL执行顺序中处于SELECT阶段末尾，晚于WHERE、GROUP BY。这意味着：如果先开窗再WHERE，数据库会为所有原始行（包括你马上要过滤掉的）都执行一遍昂贵的窗口计算。
例如查“活跃用户最近3笔订单”，写成SELECT * FROM (SELECT *, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) AS rn FROM orders) t WHERE status = 'active' AND rn ，就会对全部订单（含inactive）编号，浪费巨大。
- 正确做法：先把无关数据筛掉，再开窗：
SELECT *, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) AS rn FROM orders WHERE status = 'active' - 性能陷阱：EXPLAIN ANALYZE中看到
WindowAgg节点耗时占比高，且输入行数远超预期，基本就是WHERE位置错了 - 额外限制：窗口函数输出的是表达式值，不能直接用于WHERE或HAVING；想筛“部门平均薪资 > 15000”的员工，必须套CTE或子查询
最易被忽略的一点：开窗函数不是语法糖，它是独立的计算层。你可以在GROUP BY之后再开窗，也可以在WHERE之后、甚至在另一个窗口函数结果上再套一层OVER——这种嵌套能力，GROUP BY完全不具备。用错场景时它比GROUP BY更重；用对地方时，它让原本要三段SQL才能表达的逻辑，浓缩成一行。
