WHERE中直接使用ROW_NUMBER()报错，因SQL执行顺序中WHERE在SELECT之前，窗口函数仅在SELECT阶段计算，此时别名rn尚未生成，导致列不存在或语法不被允许。
WHERE里直接写ROW_NUMBER()为什么一定报错
因为SQL执行顺序中WHERE在SELECT阶段之前，而窗口函数（如ROW_NUMBER()、RANK()）只在SELECT里计算。此时别名rn根本不存在，数据库连列名都找不到——不是语法写错了，是时间上还没“出生”。常见报错包括：Unknown column 'rn'（MySQL）、ERROR: window functions are not allowed in WHERE（PostgreSQL）、Invalid use of window function（SQL Server）。
- 别试图用
HAVING替代：它只对GROUP BY后的聚合结果生效，对窗口函数无效 -
ORDER BY写在OVER()里，不是给最终结果排序，而是决定窗口内行的处理顺序；漏写会导致ROW_NUMBER()结果不稳定 - 哪怕子查询加了
AS t，外层WHERE t.rn = 1看着合理，底层执行计划仍不认可该列在过滤阶段可用
用派生表包裹是最通用的修复方式
把窗口函数放在内层SELECT中定义别名，外层再从这个子查询里筛选——这是兼容性最好、几乎所有支持窗口函数的数据库（MySQL 8.0+、PostgreSQL、SQL Server 2012+、Oracle、SQLite 3.25+）都认的写法。
- MySQL要求子查询必须带别名，否则报
Every derived table must have its own alias - 内层
SELECT中定义的rn，只能在外层WHERE引用，不能在内层WHERE用 - 嵌套超过三层会让语句难读难调，单层窗口逻辑优先选这种写法
示例：
SELECT name, dept_id, salary FROM ( SELECT *, ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY salary DESC) AS rn FROM employees ) t WHERE rn <= 3;
CTE更适合多步窗口或需要复用中间结果
当你要连续用多个窗口函数（比如先RANK()再LAG()），或者后续还要查一遍中间结果，用WITH比层层嵌套子查询更清晰。
- CTE不是物化表，多数引擎不会真存数据，但命名语义强，调试时可单独运行
SELECT *看中间结果 - 别在CTE里写
SELECT *，只选真正需要的字段，减少内存和网络开销 - MySQL 5.7及更早版本不支持窗口函数，执行前先确认
SELECT VERSION()
示例：
WITH ranked AS (
SELECT id, user_id, amount,
RANK() OVER (PARTITION BY user_id ORDER BY amount DESC) AS rnk,
SUM(amount) OVER (PARTITION BY user_id) AS total_by_user
FROM orders
)
SELECT id, user_id, amount, rnk
FROM ranked
WHERE rnk = 1;
LIMIT和窗口函数不能同层出现
MySQL明确禁止在同一个子查询里同时写窗口函数和LIMIT，报错Window function is not allowed in this context。原因在于LIMIT要截断结果，而窗口函数依赖完整行集做分区和排序，两者语义冲突。
- 错误写法：
SELECT * FROM (SELECT *, ROW_NUMBER() OVER() AS rn FROM t LIMIT 10) AS t2 WHERE rn = 1 - 正确做法：把
LIMIT移到最外层，或先完成窗口计算，再外层LIMIT - 性能隐患常被忽略：如果
OVER (PARTITION BY x ORDER BY y)里的y没索引，EXPLAIN会显示Using temporary; Using filesort，百万行可能秒级变数秒
复杂点不在语法本身，而在执行时序和物理执行计划的错位——你写的是一条SQL，数据库却按固定阶段一步步执行，窗口函数的“结果”永远比WHERE晚一步到场。
