因为SQL执行顺序中WHERE在SELECT（含窗口函数）之前执行，此时ROW_NUMBER()结果尚未生成，别名rn不存在；必须用派生表或CTE先固化窗口结果，再在外层WHERE引用。
WHERE里写ROW_NUMBER()为什么报错
不是语法写错了，是时机根本不对。SQL执行顺序固定为 FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY，而窗口函数（如 ROW_NUMBER()、RANK()）只在 SELECT 阶段才真正计算。此时 WHERE 早已跑完，连“结果列”都还没生成，数据库自然找不到 rn 这个名字——报错信息通常是 column "rn" does not exist（MySQL/PostgreSQL）或 window functions are not allowed in WHERE（PostgreSQL/SQL Server）。
怎么让窗口结果能被WHERE用
必须把窗口计算结果“固化”成可访问的列，且确保上下文清晰。只有两种可靠方式：
- 用派生表（子查询）：内层
SELECT中定义ROW_NUMBER() OVER (...) AS rn，外层FROM后跟这个子查询并显式加别名（如AS t），再在外层WHERE t.rn - 用CTE：先
WITH ranked AS (SELECT ..., ROW_NUMBER() ...)，再SELECT * FROM ranked WHERE rn = 1 - MySQL 要求子查询必须带别名，否则报
Every derived table must have its own alias - 别在子查询内部混用
LIMIT和窗口函数，MySQL 直接拒绝：Window function is not allowed in this context
PARTITION BY 和 ORDER BY 缺一不可
漏掉 PARTITION BY，ROW_NUMBER() 就对整张表编号，不是“每部门前3”，而是“全公司排前3”；漏掉 ORDER BY，编号顺序无保证——相同薪资下，哪行得第1完全依赖存储页顺序，多次执行可能返回不同结果。
ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY salary DESC) 和 ROW_NUMBER() OVER (ORDER BY salary DESC) 语义完全不同，不能靠外层 ORDER BY 补救。
容易被忽略的性能陷阱
即使语法跑通，性能也可能崩：
-
OVER (PARTITION BY user_id ORDER BY create_time DESC)若表上只有user_id索引，没有(user_id, create_time)复合索引，MySQL 会触发Using temporary; Using filesort - 窗口函数基于未被
LIMIT截断的完整中间结果集——别指望内层加LIMIT能提速，它和窗口函数不共存 - CTE 不等于物化临时表，但写
SELECT *会多传字段、多占内存，只选真正需要的列
窗口函数不是“写在哪都能用”的普通表达式，它的生命周期严格绑定在 SELECT 阶段。想过滤它的结果，就得接受封装这一步——没捷径，也绕不开执行顺序这道硬门槛。
