窗口函数在SQL逻辑执行顺序中位于GROUP BY、HAVING、SELECT之后，但早于外层ORDER BY和LIMIT，且基于未被LIMIT截断的完整结果集计算。
窗口函数在 SQL 执行流程中的位置
窗口函数不是在 WHERE 或 GROUP BY 之后“顺手算一下”，而是被安排在逻辑执行顺序靠后、但早于 ORDER BY（外层）和 LIMIT 的阶段。准确说，它在 GROUP BY、HAVING、SELECT（含普通表达式）之后执行，但它的计算仍基于未被 LIMIT 截断的完整结果集。
这意味着：你不能在 WHERE 里直接引用窗口函数结果（比如 WHERE rank() = 1），因为 WHERE 发生在它之前；也不能指望 ORDER BY 外层改变窗口内的排序逻辑——窗口自身的 ORDER BY 子句才真正决定 ROW_NUMBER() 或 AVG() OVER (ORDER BY ...) 的行为。
常见错误：把窗口函数当过滤条件用
最典型的现象是写 SELECT *, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY ts DESC) rn FROM logs WHERE rn = 1，然后报错 column "rn" does not exist —— 因为 WHERE 看不到 SELECT 里刚定义的别名。
- 正确做法是套一层子查询或 CTE：
WITH ranked AS ( SELECT *, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY ts DESC) rn FROM logs ) SELECT * FROM ranked WHERE rn = 1;
- 如果只是想取最新一条，且数据库支持（如 PostgreSQL 14+、MySQL 8.0+），可考虑
DISTINCT ON或QUALIFY（BigQuery / Snowflake），它们语义更贴近“先窗口再过滤” - 注意：CTE 并不总是物化，过度嵌套可能影响优化器判断，简单场景用子查询反而更可控
ORDER BY 在 OVER() 里到底控制什么
OVER (ORDER BY x) 不是给最终结果排序，而是定义窗口帧内行的相对顺序，直接影响 ROW_NUMBER()、RANGE 类窗口函数的值，也影响默认帧（ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW）的范围边界。
- 没写
ORDER BY？ROW_NUMBER()仍能运行，但结果不可预测（依赖物理存储顺序，不同执行可能不同） - 写了
ORDER BY x但x有大量重复值？ROW_NUMBER()仍会强制编号，而RANK()和DENSE_RANK()会并列，这点常被忽略导致分页错位 - 性能上，
ORDER BY字段最好有索引；若窗口还带PARTITION BY y，复合索引(y, x)效果通常比单列好得多
窗口函数和聚合函数混用时的陷阱
在同一个 SELECT 中同时出现 COUNT(*) 和 COUNT(*) OVER () 是合法的，但语义完全不同：前者是分组后计数（若用了 GROUP BY），后者是全结果集计数，且它不参与分组逻辑。
- 如果你写了
SELECT dept, COUNT(*), AVG(salary) OVER (PARTITION BY dept)却没加GROUP BY dept，多数数据库会报错（PostgreSQL、SQL Server），因为普通聚合和窗口聚合不能共存于无分组的 SELECT 中 - MySQL 5.7 允许这种写法但行为不标准（隐式分组），升级到 8.0 后默认禁用，需显式设置
sql_mode - 真正想“每个部门人数 + 部门平均工资”，应统一用窗口函数：
COUNT(*) OVER (PARTITION BY dept)和AVG(salary) OVER (PARTITION BY dept)，避免混用引发歧义
窗口函数的执行时机和依赖关系比表面看起来更脆弱，尤其在嵌套子查询、多层 CTE 或与外部排序/分页联动时，最容易出问题的不是语法，而是对“它到底在哪个数据快照上算”的误判。
