窗口函数不能在WHERE子句中直接使用，因执行顺序晚于WHERE；须先用子查询或CTE计算排名生成临时表，再在外层过滤；MySQL 8.0+/PostgreSQL支持CTE+RANK()，SQL Server需注意ORDER BY稳定性。
子查询里直接用RANK()会报错：窗口函数不能出现在WHERE或GROUP BY中
直接在子查询的SELECT里写
没问题，但一旦你想在外部查询里用这个排名做过滤（比如
），就会触发错误：
。根本原因是窗口函数执行阶段晚于WHERE，SQL引擎还没算出排名，WHERE就已经开始筛选了。
实操建议：
必须把带
的查询放到子查询（或CTE）里，让排名先算出来，生成一个含
列的临时结果集
外部查询再对这个结果集做条件过滤——此时
是普通列，WHERE能正常识别
别试图在子查询里加
，那会报错；得挪到外层
MySQL 8.0+ 和 PostgreSQL 可直接用CTE + RANK()，但SQL Server要注意ORDER BY写法
不同数据库对窗口函数的支持细节有差异。比如
在MySQL和PostgreSQL里可以直接用，但在SQL Server中如果子查询没写
（哪怕只是占位），外部排序可能不稳定，导致排名跳变。
实操建议：
MySQL 8.0+ 推荐用
，然后
PostgreSQL 同样支持CTE，但注意如果基表没主键，相同score可能因物理顺序不同导致排名不一致，建议加二级排序，如
SQL Server 要求子查询若含窗口函数，外部查询的
必须显式声明，否则
结果不保证可复现
WHERE里想用排名过滤？必须用子查询包裹，不能省略别名
常见错误是写成
，漏掉子查询别名，MySQL会报
；PostgreSQL则直接拒绝语法。
实操建议：
子查询必须加别名，哪怕只是
，这是硬性语法要求
生成的列名在子查询里要显式起别名，如
，否则外部引用时容易混淆
别用
穿透子查询，尤其当原表和窗口函数列同名时（比如都有
），会导致字段覆盖或歧义
用RANK()还是ROW_NUMBER()？重复值处理逻辑决定结果可信度
如果数据里有并列分数，
会跳过后续名次（如 1,1,3），而
强制连续（1,2,3）。很多业务场景要求“前3名”包含所有并列第3的人，这时用
才合理；但如果要做分页或唯一序号，
更安全。
实操建议：
查“TOP N且允许并列” → 用
，配合
查“严格取N条记录” → 用
，否则可能返回超过N行
测试时务必造重复值数据验证，比如插入两条
，看结果是否符合预期
嵌套RANK的本质不是语法技巧，而是执行顺序约束下的妥协方案——你永远不能绕过“先计算、后过滤”这个铁律。最容易被忽略的，是二级排序字段缺失导致的排名漂移，尤其在分布式或并发写入环境下。
RANK() OVER (ORDER BY score DESC)WHERE rank = 1window function is not allowed in WHERE clauseRANK()rankrankWHERE rank > 1RANK() OVER (ORDER BY score DESC)ORDER BYWITH ranked AS (SELECT ..., RANK() OVER (ORDER BY score DESC) AS rk FROM scores)SELECT * FROM ranked WHERE rk ORDER BY score DESC, id ASCORDER BYRANK()SELECT * FROM (SELECT name, RANK() OVER (...) FROM t) WHERE rank = 1Every derived table must have its own aliasAS rRANK()RANK() OVER (...) AS rkSELECT *idRANK()ROW_NUMBER()RANK()ROW_NUMBER()RANK()WHERE rk ROW_NUMBER()score = 95