窗口函数不能写在WHERE中，因为SQL执行顺序为FROM→WHERE→GROUP BY→HAVING→SELECT→ORDER BY，而窗口函数仅在SELECT阶段计算，WHERE阶段尚未生成其结果；必须用子查询或CTE“固化”后才能过滤。
窗口函数不能写在 WHERE 中，不是语法不允许，而是它根本还没算出来。
WHERE 阶段窗口函数连影子都没有
SQL 逻辑执行顺序是固定的：FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY。窗口函数（如 ROW_NUMBER()、RANK()、SUM() OVER ()）只在 SELECT 阶段才真正计算。你写 WHERE rn = 1，数据库在 WHERE 阶段连 rn 这个别名都还没见过——报错信息通常是 column "rn" does not exist（PostgreSQL/MySQL）或 window functions are not allowed in WHERE（PostgreSQL/SQL Server）。
这不是某家数据库的限制，MySQL、PostgreSQL、SQL Server、Oracle 全部一致。
想用窗口结果过滤，必须先“固化”成普通列
只有两种通用且可靠的方式：
- 用子查询（派生表）：内层
SELECT中定义ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY salary DESC) AS rn，外层FROM后跟这个子查询并加别名（如AS t），再在外层WHERE t.rn <= 3 - 用 CTE：先
WITH ranked AS (SELECT *, ROW_NUMBER() OVER (...) AS rn FROM employees)，再SELECT * FROM ranked WHERE rn = 1
注意：MySQL 要求子查询必须带别名，否则直接报 Every derived table must have its own alias；CTE 中别写 SELECT *，只选真正需要的字段，避免多传数据、多占内存。
PARTITION BY 和 ORDER BY 缺一不可
漏掉任何一个，结果就不是你想要的“每组前 N”：
- 漏
PARTITION BY→ROW_NUMBER()对整张表编号，变成全表排名，不是“每部门前 3” - 漏
ORDER BY→ 编号顺序依赖物理存储页，相同salary下哪行得第 1 完全不可控，多次执行可能返回不同结果 -
ORDER BY必须写在OVER()里，外层ORDER BY不影响窗口计算顺序
例如：ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY salary DESC, id ASC) 比只写 salary DESC 更稳定，尤其当薪资有重复时。
QUALIFY 看起来简洁，但别指望它绕过本质问题
QUALIFY 是 BigQuery、Snowflake、DuckDB、MaxCompute 等支持的语法糖，例如：SELECT *, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY ts DESC) AS rn FROM events QUALIFY rn = 1。但它只是自动帮你套了一层子查询，底层逻辑没变。
关键限制：
-
MySQL（截至 2026 年最新版）和PostgreSQL（原生）都不支持QUALIFY -
QUALIFY后必须至少包含一个窗口函数表达式，不能只写普通条件 - 它不解决
RANK()并列导致的多行问题——要保唯一，还得用ROW_NUMBER()
真正容易被忽略的，从来不是“怎么写”，而是 PARTITION BY 和 ORDER BY 是否完整、是否稳定。哪怕语法跑通了，这两处出错，结果就是错的，而且很难排查。
