如何用SQL窗口函数替换关联子查询以提升性能：实战改写JOIN案例
用窗口函数直接替换关联子查询，这事儿靠谱吗？答案是肯定的，绝大多数场景下都能实现。但问题的关键，从来不是“能不能写出来”，而是“PARTITION BY和ORDER BY这两项，你写对了没有”。这两处要是写错了，结果可能南辕北辙，性能非但没提升，反而会变得更糟。
用 A VG() OVER(PARTITION BY) 替代标量子查询
先看一个典型场景：计算每个部门的平均工资。新手常犯的错误，是把类似(SELECT A VG(salary) FROM emp e2 WHERE e2.dept = e1.dept)这样的标量子查询留在SELECT列表里。这么写，意味着每一行数据都要触发一次独立的子查询执行，一旦数据量过万，性能瓶颈就非常明显了。
- 正确写法：直接使用
A VG(salary) OVER (PARTITION BY dept)。数据库引擎只需单次扫描，就能完成所有分组的计算，效率天差地别。 - 语义对齐是关键：必须确保
PARTITION BY dept和原子查询中的WHERE e2.dept = e1.dept在语义上完全对应。字段名、NULL值处理、甚至大小写敏感度，都要一一核对。 - 警惕NULL值陷阱：如果dept字段存在NULL值，
PARTITION BY dept会把所有NULL归为同一组。然而，在传统的等值关联子查询中，e2.dept = e1.dept对NULL的比较结果会是UNKNOWN，不会匹配。这两种行为并不等价。解决方案是提前用COALESCE(dept, 'UNKNOWN')这样的函数统一处理。
用 ROW_NUMBER() OVER(...) 替代 LEFT JOIN + 子查询求最新记录
再比如，查询每个用户的最新订单。一个常见的“绕路”写法是：LEFT JOIN orders o2 ON o1.user_id = o2.user_id AND o2.created_at > o1.created_at WHERE o2.id IS NULL。这种写法逻辑绕、可读性差，而且在created_at时间戳重复时，结果可能不确定。
- 窗口函数解法：改用
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC, id DESC) AS rn，然后在外层筛选WHERE rn = 1。逻辑清晰，一目了然。 - 排序稳定性是硬性要求：
ORDER BY created_at DESC, id DESC这个细节至关重要。当时间戳完全相同时，必须依靠具有唯一性的id字段来保证排序稳定，否则同一秒内的多笔订单，每次查询的结果都可能不同。 - 性能前提：索引支持：如果表上没有
(user_id, created_at, id)这样的复合索引，这个窗口函数可能会强制进行磁盘排序，其性能可能比原来的JOIN写法还要差。动手改写前，务必先查看执行计划里有没有出现Sort节点。
用 COUNT(*) OVER(PARTITION BY ... HA VING ...) 类逻辑？不行，得换思路
有人可能会想，能不能直接在WHERE条件里用窗口函数？比如写WHERE COUNT(*) OVER (PARTITION BY dept) > 5来筛选人数大于5的部门？答案是：语法上就行不通，你会立刻收到ERROR: window functions are not allowed here的报错。
- 正确做法是分两步走：先在子查询或CTE（公共表表达式）里计算出窗口函数的值，然后在外层进行过滤。例如：
SELECT * FROM ( SELECT *, COUNT(*) OVER (PARTITION BY dept) AS dept_size FROM emp ) t WHERE dept_size > 5
- 这并非性能倒退：注意，这并非回到了嵌套子查询的老路。窗口计算
COUNT(*) OVER (PARTITION BY dept)只执行一次，外层仅仅是简单的过滤操作。相比之下，传统的WHERE dept IN (SELECT dept FROM emp GROUP BY dept HA VING COUNT(*) > 5)写法，通常需要额外扫描一次表。 - 更轻量的选择：如果只是想排除某些小分组，数据库特定语法有时更高效。例如PostgreSQL的
FILTER子句，或者使用条件聚合：COUNT(CASE WHEN ... THEN 1 END) OVER (...)。
ROWS BETWEEN 比 RANGE BETWEEN 快，但别硬套
遇到“计算过去7天累计值”的需求，很多人会下意识写出RANGE BETWEEN INTERVAL '7 days' PRECEDING AND CURRENT ROW。但在大多数情况下，这其实是一个性能陷阱。
- RANGE的代价：
RANGE是基于值的范围匹配，对于每一行，数据库都需要重新扫描，找出时间范围内的所有行。这个过程很难利用索引，数据量大时，I/O开销会急剧上升。 - 更优解：ROWS配合明确分区：更好的做法是，先确保数据按日期（如
sale_date::date）分区，然后配合ORDER BY sale_date和ROWS BETWEEN 6 PRECEDING AND CURRENT ROW。这样，窗口帧基于固定的物理行数移动，计算效率高，对CPU更友好。 - 重要前提：业务语义对齐：但这种方法有个前提：数据日期基本是连续的。如果中间某天没有数据（“断更”），那么
ROWS BETWEEN 6 PRECEDING跳过空缺日，计算的就是“最近7条记录”，而不是“最近7个自然日”。这个差异业务上是否能接受，必须和产品经理或业务方确认清楚。
最后必须强调一个最容易被忽略的核心点：窗口函数之所以快，根本原因在于它避免了数据的多次重复扫描，而不是因为它有什么“天生神力”。一旦PARTITION BY的字段缺少索引、ORDER BY的字段存在大量重复值、或者窗口帧的定义（用ROWS还是RANGE）与业务周期不匹配，那么所谓的“优化”很可能就变成了“负优化”。这才是关键所在。
