OVER子句能直接替代绝大多数“查当前行，同时要聚合其他行”的嵌套子查询，如用户总金额、最新下单时间、订单序号、滚动平均值等；必须正确使用PARTITION BY和ORDER BY顺序，缺一不可。
OVER子句能直接替代哪些嵌套子查询
绝大多数“查当前行，同时要聚合其他行”的需求，OVER子句都能一招解决，不用套两层甚至三层子查询。典型场景包括：查用户订单，同时显示该用户总金额、最新下单时间、订单序号、滚动平均值等。这类写法原来常是(SELECT SUM(amount) FROM orders o2 WHERE o2.user_id = o1.user_id)，现在直接写SUM(amount) OVER (PARTITION BY user_id)就行。
必须写对PARTITION BY和ORDER BY顺序
PARTITION BY决定分组边界，ORDER BY决定窗口内排序——顺序不能反，否则语义错乱。比如想算每个用户的订单累计金额，得写SUM(amount) OVER (PARTITION BY user_id ORDER BY order_date)；如果漏掉PARTITION BY，就变成全表累计；如果只写ORDER BY不写PARTITION BY，结果会跨用户累加，业务逻辑全崩。
- 没
PARTITION BY→ 整个结果集当一个窗口 -
ORDER BY缺失 → 窗口无序，SUM()、AVG()等聚合行为不可控（SQL Server 可能报错或返回非预期结果） -
ORDER BY字段没索引 →OVER计算时可能触发大量排序操作，尤其在大结果集上
用ROW_NUMBER()替代TOP 1子查询最稳妥
原写法中常见(SELECT TOP 1 order_date FROM orders o2 WHERE o2.user_id = u.id ORDER BY order_date DESC)，这是典型的标量子查询性能陷阱。改用ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY order_date DESC)后，在外层加WHERE rn = 1即可，执行计划稳定走索引+嵌套循环，且避免了每行都重跑子查询。
- 必须给
ROW_NUMBER()结果起别名（如rn），并在外层WHERE中引用 - 确保
orders(user_id, order_date)有复合索引，否则ORDER BY无法高效定位 - 若只要最新一条且不关心重复时间，用
DISTINCT ON（PG）不适用SQL Server，坚持ROW_NUMBER()+ 过滤
别把OVER和GROUP BY混着用
一个查询里同时出现GROUP BY和OVER很常见，但容易踩坑：如果OVER的PARTITION BY字段不在GROUP BY列表中，SQL Server 会直接报错。例如SELECT user_id, COUNT(*), AVG(amount) OVER (PARTITION BY region)，而region没出现在GROUP BY里，就会触发Msg 8120错误。
- 要么把
region加进GROUP BY（但语义可能变） - 要么先用CTE算出
region级聚合，再JOIN回主表——这时OVER反而不是最优解 - 更常见的正确姿势：用
OVER替代整个GROUP BY，比如不需要分组汇总行，只想要每行带统计值，那就别GROUP BY
真正难的是判断该不该用OVER：它适合“单行输出 + 横向扩展统计”，不适合“多行压缩 + 分组归并”。一旦发现需要先GROUP BY再算窗口，或者窗口逻辑依赖另一个聚合结果，就得切回CTE或临时表——这时候硬套OVER只会让逻辑更绕，优化器也更难发力。
