窗口函数不能用于WHERE子句，因其在SELECT阶段才计算，而WHERE执行更早；需用子查询封装并赋予别名后在外层过滤，或使用兼容性有限的QUALIFY语法。
窗口函数不能直接写在 WHERE 子句中，因为 SQL 的逻辑执行顺序决定了：当执行到 WHERE 阶段时，窗口函数压根还没运行，连结果列都不存在。
SQL 执行顺序决定了窗口函数“还没出生”
标准 SQL 逻辑执行顺序是：FROM → WHERE → GROUP BY → HAVING → SELECT（含窗口函数）→ ORDER BY。窗口函数只在 SELECT 阶段才被计算，而 WHERE 在它之前就结束了。
- 你写
WHERE rn = 1，数据库根本找不到rn这个列——报错信息如column "rn" does not exist或window functions are not allowed in WHERE就是这个原因 - 这不是数据库“不支持”，而是语义上不可能：不能用还没算出来的值去过滤数据
- 哪怕表只有一行、
ROW_NUMBER() OVER () = 1看起来理所当然，依然非法
子查询封装是最通用的绕过方式
把窗口函数放进内层 SELECT，定义别名（如 AS rn），外层再用 WHERE 过滤这个别名。这是所有主流数据库（MySQL 8.0+、PostgreSQL、SQL Server、Oracle）都支持的写法。
Presale One-pass Orchestrator
下载
一款AI工具，主要用于运行或监督单遍 Codex 实现，包含预检门控、分步计划执行及严格的 QA 缺陷闭环。适用于执行已批准的售前...，适合需要提升相关任务效率的用户。
- 子查询必须带表别名，否则 MySQL 直接报
Every derived table must have its own alias -
PARTITION BY和ORDER BY缺一不可：漏掉PARTITION BY→ 全表当一个组编号；漏掉ORDER BY→ 编号顺序依赖物理存储，结果不可复现 - 示例：
SELECT name, dept_id, salary FROM (SELECT *, ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY salary DESC) AS rn FROM employees) t WHERE t.rn = 1;
QUALIFY 看似简洁但兼容性极差
QUALIFY 是专为解决这个问题设计的语法，它在窗口计算之后、最终输出之前执行，允许直接引用窗口别名。但它只在 BigQuery、Snowflake、DuckDB、MySQL 8.0+（需开启）等少数引擎中支持，PostgreSQL 原生不认。
-
QUALIFY后必须至少包含一个窗口函数表达式，不能只写普通条件 - 它只是语法糖，底层仍等价于自动套了一层子查询；显式封装反而更可控
- 别指望
QUALIFY能绕过RANK()并列导致的多行问题——ROW_NUMBER()才能保唯一
最容易被忽略的不是“怎么写”，而是 PARTITION BY 和 ORDER BY 的完整性。哪怕语句跑通了，漏掉其中任何一个，结果就不是“每组前 N”，而是全表乱序编号或不可复现的随机序号。
