窗口函数在sql执行中位于select阶段内部，晚于普通表达式但早于distinct和order by；其计算依赖完整结果集，需先完成扫描、过滤、聚合等前置步骤，再按partition by分桶、order by排序，并依据rows/range框架逐行计算。
窗口函数的执行顺序在SQL生命周期中很特殊
MySQL 8.0 并不是在 GROUP BY 之后、SELECT 之前“顺手”算窗口函数，而是把它安排在 SELECT 列计算阶段内部，且晚于普通表达式求值但早于 DISTINCT 和 ORDER BY。这意味着：你不能在 WHERE 或 HAVING 中引用窗口函数结果，也不能用它做分组依据——它们根本还没出生。
真正关键的是：窗口函数的计算依赖完整的结果集（或满足 WHERE 条件后的中间结果），所以执行器必须先完成扫描、连接、过滤、聚合（如果有的话），再为每一行构造“窗口上下文”，最后逐行调用窗口算子。这和传统聚合函数“边扫边合”的流式处理完全不同。
-
OVER()中没写PARTITION BY时，整个结果集就是一个窗口，所有行共享一个计算上下文 - 写了
PARTITION BY deptno后，执行器会按deptno值对内存中的行做逻辑分桶，每个桶独立维护自己的排序状态和帧边界 - 如果
ORDER BY字段存在重复值，且未加唯一性约束（比如没带id），ROW_NUMBER()的结果可能不稳定——这不是 bug，是确定性排序缺失导致的
ROWS BETWEEN 是执行器真正干活的“指令集”
很多同学以为 ORDER BY 决定了窗口函数怎么算，其实真正控制“算哪几行”的是 ROWS BETWEEN 子句。执行器拿到这个定义后，会为每一行动态定位它的“前驱行集合”和“后继行集合”，再把对应行的字段值喂给聚合函数。
例如 SUM(sal) OVER (PARTITION BY deptno ORDER BY hiredate ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)，执行器不会缓存整个部门所有员工数据，而是：按 hiredate 排好序后，对当前行，从分区首行开始累加到当前行 —— 这是典型的“前缀和”扫描模式，内存友好，但要求排序必须完成。
-
ROWS BETWEEN 1 PRECEDING AND 1 FOLLOWING：只取前后各一行，适合移动平均，执行器只需维护一个三行滑动缓冲区 -
RANGE BETWEEN INTERVAL 7 DAY PRECEDING AND CURRENT ROW：这是基于值的范围，执行器需做额外比较，性能通常比ROWS差 - 省略
ROWS或RANGE时，MySQL 默认行为是RANGE UNBOUNDED PRECEDING AND CURRENT ROW，注意这可能导致隐式去重（相同ORDER BY值的行被当做一个点）
执行器如何处理 RANK() 和 ROW_NUMBER() 这类无参数函数
ROW_NUMBER()、RANK() 看似不带参数，但执行器内部仍需维护两个状态：当前分区的行计数器 + 当前排序键的“上一个值”。它不是靠查表实现的，而是在扫描已排序的分区数据流时，边读边更新这两个变量。
区别在于：ROW_NUMBER() 每读一行就 +1；RANK() 在遇到和上一行相同 ORDER BY 值时，跳过后续编号，直到值变化才重置步长——这要求执行器必须记住“上一个键值”和“当前排名起始号”，属于轻量级状态机。
- 如果
ORDER BY列有 NULL，默认按NULLS LAST处理，但 MySQL 8.0 不支持显式声明NULLS FIRST/LAST，NULL 总是排在最前或最后（取决于排序方向） -
DENSE_RANK()的状态更简单：只记“上一个键值”，相同时不跳号，变化时 +1 - 所有排名函数都**不支持**在
OVER()中指定ROWS框架——它们天然绑定整分区有序序列，框架子句会被忽略
为什么有些窗口查询慢得反常
表面看只是加了个 OVER()，但背后执行器可能触发全表排序、多轮内存分组、甚至临时磁盘文件。最常见瓶颈不在函数本身，而在 OVER() 定义引发的隐式资源需求。
- 没写
PARTITION BY却有大结果集 → 执行器被迫把全部数据拉进内存排序，OOM 风险陡增 -
PARTITION BY字段基数极高（如用户ID），导致成千上万个微小分区 → 分区管理开销压倒计算开销 - 在
ORDER BY中用了函数表达式（如YEAR(create_time)），无法利用索引，强制 Filesort - 混合使用多个不同
OVER()子句（如同时要ROW_NUMBER()和LAG()），执行器可能为每个窗口单独走一遍排序流程，而不是复用
真正容易被忽略的是：窗口函数的性能高度依赖前置排序质量。如果你的查询本就有 ORDER BY，且和某个 OVER() 的 ORDER BY 完全一致，优化器有时能复用排序结果；但只要字段顺序、方向或表达式稍有差异，就会重新排序——这点在 explain 输出里看不到，只能靠 trace 或 performance_schema 观察 sort_merge_passes。
