写SQL的时候，子查询嵌套几乎是绕不开的坑。一层套一层，刚开始还能看懂，等业务逻辑复杂起来，三四层嵌套之后连自己都不知道里层到底在过滤什么。更麻烦的是，关联子查询在数据量大的时候性能往往惨不忍睹。其实大部分这类问题，窗口函数都能给出更干净的解法。它能在不改变行数的前提下完成分组计算、排名、取值等操作，天然适合替代一大批子查询场景。
为什么窗口函数比嵌套子查询更适合这类场景
先明确窗口函数的定位：它不会像GROUP BY那样把多行聚合成一行，而是在保留每一行原始数据的基础上，额外计算出一列结果。这个特性非常关键，因为它意味着你不需要为了同时拿到明细和聚合值，先把表聚合一次再JOIN回去。
举个例子，常见的需求是查询每个部门工资高于本部门平均工资的员工。传统写法需要一个关联子查询：
SELECT e.name, e.dept_id, e.salary
FROM employee e
WHERE e.salary > (
SELECT AVG(salary)
FROM employee
WHERE dept_id = e.dept_id
);这个写法的问题在于，子查询对外层的每一行都要重新执行一次（虽然优化器可能改写，但不保证）。用窗口函数改写后，只需一次扫描：
SELECT name, dept_id, salary
FROM (
SELECT name, dept_id, salary,
AVG(salary) OVER (PARTITION BY dept_id) AS avg_salary
FROM employee
) t
WHERE salary > avg_salary;注意这里外层还是套了一层查询，因为大部分数据库不允许在WHERE里直接引用窗口函数。这是窗口函数使用的基本套路：先在内层计算，再在外层过滤。
几个高频场景的重构实战
场景一：分组取Top N记录
每个分类下销量前三的商品，这个需求用子查询写会相当痛苦，通常要按分组找最大值再逐层比较。而用ROW_NUMBER或RANK就很直观：
SELECT product_name, category, sales
FROM (
SELECT product_name, category, sales,
ROW_NUMBER() OVER (
PARTITION BY category
ORDER BY sales DESC
) AS rn
FROM product_sales
) t
WHERE rn <= 3;这里有个细节需要注意：如果希望并列的记录都保留，比如销量相同的商品算并列第一，应该用RANK()或者DENSE_RANK()。ROW_NUMBER会强制给出唯一序号，并列记录会被随机丢弃一条，这在业务上是不可接受的风险。
场景二：去重时保留最新记录
数据表里存在重复插入，只保留每个用户最新一条记录，这也是子查询的重灾区。典型子查询写法是先按用户分组取MAX(create_time)，再回表关联查询。窗口函数版本：
SELECT user_id, order_no, create_time
FROM (
SELECT user_id, order_no, create_time,
ROW_NUMBER() OVER (
PARTITION BY user_id
ORDER BY create_time DESC
) AS rn
FROM user_order
) t
WHERE rn = 1;这种写法在清理脏数据的场景中尤其好用。如果数据量特别大，还可以在PARTITION BY的排序字段上建复合索引，让数据库尽量利用索引完成分区内的排序。
场景三：计算累计值和同比环比
按日期累计销售额是报表系统的常见需求。老式做法是自关联，让每一行和它之前的所有行JOIN起来再SUM，数据量一上去就是灾难。窗口函数提供了专用的帧语法：
SELECT order_date,
amount,
SUM(amount) OVER (
ORDER BY order_date
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
) AS running_total
FROM daily_sales;ROWS BETWEEN ... AND ...定义了窗口帧的范围，从分区第一行累加到当前行。如果要算移动平均，比如近7天的平均值，把UNBOUNDED PRECEDING换成6 PRECEDING就行。这类计算用子查询几乎没法优雅实现，窗口函数是唯一合理的方案。
场景四：利用LAG和LEAD做行间比较
计算环比增长率需要拿到上一行的值，子查询写法要自关联两次。LAG函数直接解决：
SELECT order_date, amount,
LAG(amount) OVER (ORDER BY order_date) AS prev_amount,
ROUND(
(amount - LAG(amount) OVER (ORDER BY order_date))
/ LAG(amount) OVER (ORDER BY order_date) * 100, 2
) AS growth_rate
FROM daily_sales;为了可读性，也可以先在内层用子查询取出LAG的值，外层再算增长率，避免重复书写窗口表达式。
重构时的注意事项和兼容性问题
窗口函数虽然好用，但有几个坑要提前知道。第一，WHERE和GROUP BY阶段无法引用窗口函数，因为窗口计算发生在这些阶段之后，只能在SELECT列表或ORDER BY中使用，过滤必须外包一层查询。第二，PARTITION BY的分区键选择要克制，分区键过多会导致每个分区行数太少，窗口计算失去意义，还增加排序开销。
兼容性方面，MySQL从8.0版本才开始支持窗口函数，老版本只能继续用子查询或变量模拟；PostgreSQL、Oracle、SQL Server的支持都比较完善，其中Oracle还提供了KEEP (DENSE_RANK FIRST)这类专有语法，可以视情况替代。不同数据库支持的窗口函数清单略有差异，比如某些数据库不支持PERCENT_RANK之外的分位数函数，重构前最好先确认目标库的文档。
性能上也不要迷信窗口函数一定更快。如果分区数极多而每个分区行数很少，排序成本可能超过子查询方案；窗口函数也无法直接利用某些针对关联子查询的优化路径。建议在重构后用EXPLAIN对比执行计划，确认扫描次数和排序方式是否真的改善。总体来说，对于分组取值、排名、累计计算这几类问题，窗口函数在可读性和可维护性上的收益是确定的，性能提升则要结合实际数据分布来验证。
最后给一个重构建议：遇到子查询时先问自己三个问题，内层查询是在做分组聚合吗？需要保留明细行吗？子查询和外层是按同一组键关联的吗？如果三个答案都是肯定的，那这个子查询大概率可以用窗口函数重写，而且改写后的代码会更短、更清晰。