窗口函数 ROW_NUMBER() 是 SQL 查询中非常高频的实用工具，但真正上手时，许多细节往往比预想中更复杂。不少人写过 SELECT ROW_NUMBER() 就直接扔进数据库执行，结果遇到报错一脸茫然。今天我们就来系统梳理这些容易踩坑的细节，帮你彻底掌握 SQL 窗口函数 ROW_NUMBER 的正确用法与排序逻辑。
ROW_NUMBER() 必须搭配 OVER()，否则直接报错
单独写 ROW_NUMBER() 是行不通的——数据库解析器根本不识别这种写法。它并非普通聚合函数，而是典型的 窗口函数，必须绑定 OVER() 子句才能正常运行。
常见的报错信息通常是这样：ERROR: window function ROW_NUMBER requires an OVER clause
OVER()里至少需要包含ORDER BY，即使你只想要一个随机编号，也必须指定一列（比如ORDER BY id）- 如果遗漏
ORDER BY，语句会直接卡死，数据库并不会“默认按主键排序”或“按插入顺序自动编号” PARTITION BY是可选参数，但位置必须放在ORDER BY之前，顺序写反同样无法执行
全局排序与分组内排序，区别全在 PARTITION BY
是否需要分组排序，完全由 PARTITION BY 决定。它并不是“锦上添花”的功能，而是一个逻辑开关，用与不用结果截然不同。
- 如果想给整张表所有行从 1 开始连续编号 → 使用
OVER (ORDER BY created_at DESC)，不加PARTITION BY - 如果想按用户分组，并在每个用户内部独立编号 → 必须写成
OVER (PARTITION BY user_id ORDER BY order_time DESC) - 如果漏写
PARTITION BY却自以为实现了“每组 Top 1”，实际取出来的是全表第一条数据，而不是每组的第一条——这个坑确实有不少人踩过
ORDER BY 多字段组合决定编号的稳定性
ORDER BY 不仅影响谁排在前面，更关键的是编号结果能否稳定复现。当排序字段出现重复值时，仅依赖单个字段很容易产生不确定性。
- 举例来说：按
salary DESC排序，但多人薪资相同 → 数据库在不同执行时机可能给同一行分配不同的rn值 - 解决办法很简单：添加二级排序字段，比如
ORDER BY salary DESC, emp_id ASC，让排序逻辑完全确定下来 - 在分布式查询或高并发执行环境下，这种不确定性更容易暴露——它并非偶发 bug，而是设计阶段就应主动规避的风险
ROW_NUMBER() 与 RANK() / DENSE_RANK() 切勿混用
三者都执行编号，但行为差异直接影响业务结果。用错一个，Top N 查询或数据去重就可能出现遗漏或重复。
ROW_NUMBER()：强制唯一编号，相同值也赋予不同序号（1,2,3）RANK()：相同值赋予相同序号，并跳过后续序号（1,1,3）DENSE_RANK()：相同值赋予相同序号，但不跳过序号（1,1,2）- 典型误用场景：使用
ROW_NUMBER()+WHERE rn = 1去获取“所有最高分员工”，结果只返回了一个人；正确的做法是改用RANK()才能完整取出
实际应用中，最容易忽视的就是排序字段的确定性。缺少二级排序的 ORDER BY 在生产环境里往往表现不稳定，尤其当数据量庞大、查询并发较高时，同一语句多次执行可能返回不同的 rn 值——这并非危言耸听，而是真实踩过的教训。
