不能。窗口函数在SQL执行顺序中晚于WHERE，此时尚未计算，结果列不存在，导致数据库报错；标准顺序为FROM→WHERE→GROUP BY→HAVING→SELECT（含窗口函数）→ORDER BY；必须用子查询或CTE先固化结果才能过滤。
不能。窗口函数在 SQL 执行顺序中晚于 WHERE，此时它根本还没计算，连结果列都不存在，数据库自然报错——这不是语法限制，而是时序问题。
WHERE 阶段窗口函数压根没运行
SQL 标准执行顺序是：FROM → WHERE → GROUP BY → HAVING → SELECT（含窗口函数）→ ORDER BY。ROW_NUMBER()、RANK() 这些只在 SELECT 阶段才开始分区、排序、编号，WHERE 早就跑完了。
- PostgreSQL 报：
window functions are not allowed in WHERE - MySQL 报：
Unknown column 'rn'（不是字段名写错，是真没这列） - SQL Server 报：
Invalid use of window function
你写的 WHERE rn = 1 不是“条件不成立”，而是“rn 这个名字在那一刻根本没被定义”。
必须用子查询或 CTE 先固化结果
让窗口函数的结果变成一张临时表里的真实列，才能被外层过滤。这是唯一通用、可靠的方式。
- 子查询适合单层逻辑：内层
SELECT中定义ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY salary DESC) AS rn，外层WHERE t.rn ；MySQL 要求子查询必须带别名，否则报 <code>Every derived table must have its own alias - CTE 更适合多步：比如先
RANK()再算SUM() OVER ()，中间结果可复用，语义也更清晰；但注意WITH ranked AS (...) SELECT * FROM ranked WHERE rnk = 1里，rnk是 CTE 内定义的，外层可直接引用 - 别在子查询或 CTE 里写
SELECT *，只选真正需要的字段，避免传输和内存浪费
PARTITION BY 和 ORDER BY 缺一不可
漏掉任一个，ROW_NUMBER() 就不是你想要的“每组前 N”。
- 漏
PARTITION BY→ 全表当一个组编号，结果等价于按全局排序取前 N - 漏
ORDER BY→ 编号顺序依赖物理存储，同一语句多次执行可能返回不同行；尤其在没有主键或时间精度不足（如created_at只到秒）时，必须补唯一字段，例如ORDER BY created_at DESC, id DESC -
ORDER BY在OVER里控制的是窗口内行的处理顺序，不是最终输出顺序——它直接影响编号、滑动计算（如AVG() OVER (ORDER BY ts ROWS BETWEEN 2 PRECEDING AND CURRENT ROW)）的准确性
QUALIFY 是语法糖，但别依赖它
QUALIFY 看起来简洁：SELECT *, RANK() OVER (...) AS rnk FROM t QUALIFY rnk = 1，但它只在 BigQuery、Snowflake、DuckDB、MySQL 8.0+（需开启）等少数引擎中支持，PostgreSQL 原生不认。
-
QUALIFY本质就是自动套了一层子查询，显式封装反而更可控 - 它不能解决
RANK()并列导致的多行问题——要保唯一，必须用ROW_NUMBER() - 哪怕引擎支持，也别指望它能绕过索引缺失带来的性能问题：比如
PARTITION BY user_id ORDER BY create_time，若表上只有user_id单列索引，MySQL 会回表+文件排序，EXPLAIN显示Using temporary; Using filesort
最常被忽略的，其实是 PARTITION BY 和 ORDER BY 的完整性——语法跑通了，不代表逻辑对。哪怕只漏一个字段，结果就已偏离业务本意。
