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