窗口函数比关联子查询更易维护，因其将“跨行计算逻辑”集中于over()中一处定义、全局复用；而关联子查询需多处同步修改，嵌套深、易出错、难调试。
窗口函数比关联子查询更容易维护，根本原因在于它把“跨行计算逻辑”从分散、重复的嵌套结构里抽出来，变成一处定义、全局生效的声明式表达。
子查询维护时要同步改多处
比如想给每个员工加一个“部门内薪资排名”，用关联子查询写成：
SELECT e1.name, e1.salary, (SELECT COUNT(*) + 1 FROM emp e2 WHERE e2.dept_id = e1.dept_id AND e2.salary > e1.salary) AS rank_in_dept FROM emp e1;
一旦需求变成“只统计在职员工”，你得同时改两处：e2 子查询里的 WHERE 条件，和外层 e1 的过滤条件。漏改一处，结果就错。
- 新增字段（如加个“部门平均薪资”）需再套一层子查询，嵌套加深，可读性断崖下跌
- 修改排序逻辑（比如从按 salary 改为按 salary + bonus）要翻找所有子查询里的
ORDER BY或比较表达式 - 无法复用计算逻辑——同一组
PARTITION BY dept_id ORDER BY salary在多个子查询里重复写，改一处就得全手动同步
窗口函数把逻辑集中到 OVER() 里
等价逻辑用窗口函数只需写一次定义：
SELECT name, salary, RANK() OVER (PARTITION BY dept_id ORDER BY salary DESC) AS rank_in_dept, AVG(salary) OVER (PARTITION BY dept_id) AS avg_dept_salary FROM emp WHERE status = 'active';
所有衍生计算都依赖同一个 PARTITION BY dept_id 和 ORDER BY salary DESC，改分区或排序，只动 OVER() 里的参数。
- 新增计算列不增加嵌套层级，直接追加新函数即可
- 过滤条件统一写在最外层
WHERE，不用在每个子表达式里重复判断 -
PARTITION BY字段有索引时，数据库可能复用排序结果，多个窗口函数共享一次排序开销
调试时能一眼看出数据范围边界
子查询的执行范围隐含在 WHERE 条件里，比如 e2.salary > e1.salary AND e2.dept_id = e1.dept_id，你得脑内模拟每行触发的子集；而窗口函数的范围明确定义在 OVER(PARTITION BY ... ORDER BY ... ROWS BETWEEN ...) 中。
-
ROWS BETWEEN 1 PRECEDING AND CURRENT ROW→ 清晰表示“当前行和上一行” -
RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW→ 明确是“从分区开头累计到当前行” - 出错时看执行计划里的
WINDOW节点，比追踪一堆DEPENDENT SUBQUERY直观得多
真正难维护的不是语法本身，而是当业务规则变复杂（比如“排除试用期员工”“按季度重置排名”“跨年滚动计算”），子查询会迅速变成意大利面条代码；而窗口函数只要调整 PARTITION BY 和 ROWS/RANGE 的组合，就能精准控制计算粒度——这个控制权，必须亲手写进 OVER() 里，没法靠优化器猜。
