WHERE中不能使用窗口函数是因为其执行时机早于SELECT，此时窗口函数尚未计算；正确做法是用子查询或CTE先生成序号列，再在外层WHERE中过滤。
因为SQL执行顺序中WHERE在SELECT之前运行，而窗口函数只在SELECT阶段才计算——此时ROW_NUMBER()、RANK()这些值根本还没生成，数据库连列名都找不到。
WHERE里写ROW_NUMBER()为什么会报错
不是语法写错了，是时机根本不对。典型错误写法：SELECT * FROM orders WHERE ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY ts DESC) = 1。报错信息可能是：window functions are not allowed in WHERE（PostgreSQL）、Invalid use of window function（SQL Server）或Unknown column 'rn'（MySQL）。这些都不是拼写问题，而是WHERE阶段窗口函数压根没“出生”——它依赖的分区、排序、编号动作都还没开始。
必须用子查询或CTE先固化结果
窗口函数的结果要能被WHERE过滤，就得先变成一个“真实存在”的列。只有两种可靠方式：
- 用派生表（子查询）：内层
SELECT中定义ROW_NUMBER() OVER (...) AS rn，外层FROM后跟这个子查询并加别名（如AS t），再在外层WHERE t.rn - 用CTE：先
WITH ranked AS (SELECT ..., ROW_NUMBER() OVER (...) AS rn FROM ...)，再SELECT * FROM ranked WHERE rn = 1 - MySQL要求子查询必须带别名，否则直接报
Every derived table must have its own alias - CTE里别写
SELECT *，只选真正需要的字段，避免内存和网络开销
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补救。
最容易被忽略的，其实是ORDER BY在OVER()里的作用：它不控制最终输出顺序，只决定窗口内行的处理顺序——比如SUM() OVER (ORDER BY ts ROWS BETWEEN 2 PRECEDING AND CURRENT ROW)的滑动计算，没有它就连“preceding”是谁都定不了。
