WHERE中不能使用ROW_NUMBER()等窗口函数，因为SQL执行顺序中WHERE在窗口函数计算之前执行，此时窗口函数结果尚未生成，导致语法错误；解决方法是用子查询包裹，外层WHERE筛选内层定义的别名。
WHERE里写ROW_NUMBER()为什么会报错
因为SQL执行顺序中，WHERE在窗口函数计算之前就完成了。这时ROW_NUMBER()、RANK()这些值根本还没生成，数据库连“列都不存在”，自然报ERROR: window functions are not allowed in WHERE（PostgreSQL）或Invalid use of an aggregate or window function（SQL Server）。
这不是语法限制，而是逻辑时序问题：你不能用还没算出来的数去过滤数据。
用子查询包裹是最直接的解法
把带窗口函数的查询作为内层查询，外层再用WHERE筛选别名——这是兼容性最好、理解成本最低的方式。
- 适合单层窗口逻辑，语句轻量，优化器通常能较好识别
- 注意别名必须在外层引用，内层
SELECT中定义的rn在内层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比子查询更适合多步逻辑
当需要连续使用多个窗口函数（比如先排名、再计算累计占比），或者后续还要复用中间结果时，WITH更清晰。
-
CTE不是物化视图，多数引擎不会真存一份临时表，但命名语义强，调试方便 - MySQL 8.0+、PostgreSQL、SQL Server 2012+、Oracle、SQLite 3.25+ 都支持，旧版MySQL（
- 别在CTE里写无谓的
SELECT *，只选真正需要的字段，减少传输和内存开销
示例：
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;
ORDER BY在OVER里到底控制什么
OVER (ORDER BY x)不是给最终结果排序，而是决定窗口内行的处理顺序——它直接影响ROW_NUMBER()编号、ROWS BETWEEN范围边界，以及AVG() OVER (ORDER BY ts ROWS BETWEEN 2 PRECEDING AND CURRENT ROW)这类滑动计算的准确性。
- 漏写
ORDER BY会导致ROW_NUMBER()结果不稳定（尤其没主键或唯一排序依据时） - 在
PARTITION BY后仅靠ORDER BY无法保证全局唯一排序，可能产生相同RANK()值，需结合id等字段做二级排序 -
ORDER BY字段如果没有索引，大表上会显著拖慢窗口计算速度
真正容易被忽略的是：你在OVER里写的ORDER BY，和最外层ORDER BY毫无关系——后者只影响最终返回顺序，不改变窗口值本身。
