窗口函数能替代用于“每组内计算聚合值并保留原行”的子查询，如部门薪资排名、累计薪资、部门平均薪资等；但无法替代WHERE中的标量子查询、多层相关子查询及FROM中的表子查询。
窗口函数能替代哪些子查询？
窗口函数可以替代一部分子查询，尤其是那些用于“每组内计算聚合值并保留原行”的场景。比如要查每个部门员工的薪资排名、累计薪资、部门平均薪资等，用 ROW_NUMBER()、AVG() OVER (PARTITION BY dept) 比关联子查询或自连接更简洁高效。
但不能替代所有子查询。典型无法替代的包括：
- 子查询作为
WHERE条件中的标量子查询（如WHERE salary > (SELECT AVG(salary) FROM emp)），窗口函数无法直接参与过滤逻辑 - 多层嵌套且依赖外部作用域的子查询（如相关子查询中引用外层
WHERE条件） - 返回多行多列的子查询（如
FROM (SELECT ...) t），窗口函数只能扩展当前行，不能新增/删减行
性能差异在哪？
窗口函数通常比等效的关联子查询快，因为只需一次扫描即可完成分组内计算；而子查询在无优化时可能对每行重复执行（尤其相关子查询）。
但要注意：
- 窗口函数的
ORDER BY和大范围ROWS BETWEEN会显著增加内存和排序开销 - 某些数据库（如 MySQL 8.0 前）不支持窗口函数，强行改写会导致语法错误
- 如果只是需要单个聚合值（如整个表的平均值），用子查询
(SELECT AVG(x) FROM t)比AVG(x) OVER()更轻量——后者会为每一行重复输出相同值，徒增结果集体积
哪些子查询改写后反而更难懂？
不是所有能改写的都该改。以下情况建议保留子查询：
- 业务逻辑天然分步：比如先算出“近30天活跃用户ID”，再用这些 ID 查订单，拆成两个子查询比塞进一个带
LAG()和复杂FILTER的窗口表达式更清晰 - 使用了数据库特有子查询优化（如 PostgreSQL 的
LATERAL或 Oracle 的WITH子句），强行窗口化可能丢失执行计划优势 - 需要
DISTINCT ON或TOP 1 per group但排序字段与分区键不一致时，用ROW_NUMBER() OVER (PARTITION BY ... ORDER BY ...)虽可行，但可读性常不如SELECT DISTINCT ON (group_col) ... ORDER BY group_col, priority_col
实际选型的关键判断点
决定用窗口函数还是子查询，看三个事实：
- 是否必须保留原始行数？是 → 优先窗口函数
- 计算是否依赖其他行的动态范围（如移动平均、同比环比）？是 → 窗口函数几乎是唯一选择
- 过滤条件是否基于跨行聚合结果？比如“只显示高于本部门平均薪资的员工” → 可用窗口函数先算均值，再用外层
WHERE过滤，但注意这实际是两阶段处理，不是单条语句“内联”完成
窗口函数不是子查询的升级版，而是不同抽象层级的工具。混淆它们的职责边界，容易写出既慢又难维护的 SQL。
