ROW_NUMBER() 与 RANK()：一字之差，逻辑天壤之别

ROW_NUMBER() 和 RANK() 的结果差异，根本不在写法，而在排序逻辑

许多开发者在编写SQL窗口函数时，语法看似正确，但查询结果却与预期不符。问题的根源往往不在于代码本身，而在于对ROW_NUMBER()和RANK()这两个核心函数的内在逻辑理解不足。它们对重复值的处理方式存在本质区别，这正是SQL面试和实际开发中的关键考点。

• ROW_NUMBER() 严格按行分配唯一序号，无视数值是否相等。即使两行记录的salary字段完全相同（例如都是25000），它也会强制分配连续编号1和2。
• RANK() 则遵循现实世界的排名规则：数值相同则名次并列，后续名次会跳过被占用的序号。例如，出现两个第一名后，下一个名次直接就是第三名。
• 通过一个经典案例可以清晰对比：对数据集[90, 85, 85, 80]执行降序排名，SELECT score, ROW_NUMBER() OVER (ORDER BY score DESC), RANK() OVER (ORDER BY score DESC)，两者的输出结果分别为[1,2,3,4]和[1,2,2,4]。这直观展示了SQL排名函数的核心差异。

选哪个？取决于你到底要“序号”还是“名次”

选择ROW_NUMBER()还是RANK()，绝非个人编码风格问题，而是直接关系到业务逻辑的准确性。用错函数可能导致数据分析结论完全错误。

• 需要唯一序号时用ROW_NUMBER()：例如，获取每个部门最新的一条订单记录。应使用ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY create_time DESC)生成序号，再通过WHERE rn = 1筛选。此场景要求序号绝对唯一，不允许并列。
• 需要真实排名时用RANK()：例如，制作销售业绩排行榜，且需处理并列情况。应使用RANK() OVER (ORDER BY amount DESC)，配合WHERE rk <= 3筛选前三名。这样，如果两人并列第一，一人第三，查询结果将正确返回三条记录。
• 常见误区警示：若错误地使用ROW_NUMBER()来实现“取前三名”，系统只会机械地返回前三行，所有并列的选手都会被遗漏。这是SQL面试和线上数据事故中的高频错误点，务必警惕。

常见踩坑点：别名不能直接在 WHERE 里用，PARTITION BY 写错就全乱了

窗口函数的使用存在几个典型陷阱。首先，由于SQL执行顺序（WHERE在SELECT之前计算），窗口函数生成的别名无法在同一查询层级的WHERE子句中直接引用。其次，PARTITION BY的分组维度一旦定义错误，整个排名逻辑将彻底失效。

• 错误写法示例：SELECT *, RANK() OVER (ORDER BY score) AS rk FROM scores WHERE rk <= 10。此语句将导致报错或逻辑混乱。
• 正确解决方案：必须使用子查询或公共表表达式（CTE）进行嵌套，在外部查询中过滤。例如：SELECT * FROM (SELECT *, RANK() OVER (...) AS rk FROM scores) t WHERE t.rk <= 10。
• 分组维度核对：如果将PARTITION BY dept_id误写为PARTITION BY city