窗口函数保留原表行数且支持跨行计算，子查询聚合会压缩行数、无法天然附着明细；因name未被GROUP BY或聚合包裹而报错，相关子查询性能差且难维护；OVER()通过PARTITION BY分区、ORDER BY排序、ROWS/RANGE帧控范围，实现滚动计算与累计求和。
窗口函数不压缩行数，子查询聚合会；想保留明细又加汇总值，别用子查询硬套GROUP BY。
为什么子查询聚合后查不到员工姓名
常见错误是写成：SELECT name, AVG(salary) FROM employees GROUP BY department——直接报错或结果错乱。因为name既没出现在GROUP BY里，也没被聚合函数包裹，违反SQL标准（尤其sql_mode=only_full_group_by开启时）。
子查询本身不解决这个问题：哪怕用(SELECT AVG(salary) FROM employees e2 WHERE e2.department = e1.department)这种相关子查询，虽能跑通，但性能差（外层每行触发一次内层扫描），且逻辑分散、难维护。
- 子查询聚合本质仍是“先分组再返回单值”，它无法天然附着到原表每一行
- 若强行JOIN派生表，需确保关联键唯一（如用部门ID），否则可能因一对多导致重复或丢失
- MySQL 5.7及更早版本不支持窗口函数，才被迫用子查询+变量等迂回方案，但稳定性差
窗口函数怎么避免GROUP BY的折叠效应
关键在OVER()子句替代GROUP BY：它分区但不分组，保留原始行结构。
例如统计每个员工所在部门的平均工资：SELECT name, salary, AVG(salary) OVER (PARTITION BY department) AS dept_avg_salary FROM employees——输出行数=原表行数，name和salary全保留，dept_avg_salary是计算列。
-
PARTITION BY department定义“和谁比”，等价于GROUP BY的分组逻辑，但不删行 - 不写
ORDER BY时，AVG()等聚合类窗口函数默认对整个分区计算；加ORDER BY后必须配ROWS或RANGE帧，否则某些数据库会报错或行为不一致 - 同一查询可混用：比如
COUNT(*) OVER (PARTITION BY department)算部门人数，同时ROW_NUMBER() OVER (PARTITION BY department ORDER BY salary DESC)排薪资名次
ROWS和RANGE帧在窗口函数里到底影响什么
这是子查询完全无法模拟的能力：窗口函数能定义“当前行参考哪些邻近行”，子查询只能返回一个标量值。
例如滚动7日销量：SUM(sales) OVER (ORDER BY order_date ROWS BETWEEN 6 PRECEDING AND CURRENT ROW)——严格按物理行偏移，每天只算最近7条记录；而RANGE BETWEEN 6 PRECEDING AND CURRENT ROW会按order_date值找“过去6天内所有订单”，遇到同一天多笔订单就全包进来，结果可能突增。
-
ROWS看行号位置，RANGE看排序字段值，重复值下二者行为割裂 - 累计求和常用
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，明确边界；用RANGE则可能因时间戳重复把同天所有行都卷入，导致数值跳变 - 子查询要实现类似效果，得嵌套多层日期范围过滤，语句爆炸且难以优化
真正容易被忽略的是：窗口函数的OVER()不是装饰语法，它声明了分区、排序、帧三要素，缺一不可；而子查询只是数据源替换，没有计算上下文的概念。一旦需要跨行、带顺序、控范围的计算，子查询就退化为兜底手段，而非首选方案。
