给查询结果加行号，听起来是个挺基础的需求，但真用起来，ROW_NUMBER()这个窗口函数里藏着不少细节，一不小心就容易踩坑。今天咱们就来把几个关键点捋清楚。

ROW_NUMBER() 必须配合 OVER 子句使用，否则报错

首先得明确，ROW_NUMBER()不是个普通函数，你不能直接写个SELECT ROW_NUMBER()就完事儿。它会立刻给你抛个错误，大意是“窗口函数‘ROW_NUMBER’需要一个OVER子句”。

所以，它的最简可用形式必须是：ROW_NUMBER() OVER (ORDER BY some_column)。这里的关键在于，你得通过ORDER BY给它一个明确的排序依据，哪怕是按主键排也行。为什么？因为没有ORDER BY，数据库就无法保证每次执行时行的顺序一致，生成的行号自然也就不可预测，这次是1、2、3，下次可能就变成3、1、2了。

• 记住，ROW_NUMBER()绝不能单独出现。
• 同样，OVER ()这种空括号写法也是不合语法的。
• 如果表里实在没有合适的排序列，用ORDER BY (SELECT NULL)虽然能通过语法检查，但实际行为完全依赖数据库引擎的实现，并不推荐在生产环境使用。

给分组内数据单独编号要用 PARTITION BY

有时候，我们需要的不只是全局编号，而是分组内的独立编号。比如，想看看每个部门里员工的薪资排名，这时候光靠ORDER BY就不够了，必须请出PARTITION BY。

典型的写法是：ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY salary DESC)。注意看，PARTITION BY dept_id和ORDER BY salary DESC都在OVER的括号里，而且PARTITION BY在前。它的作用就是把dept_id值相同的行划为一组，然后在每个组内部，再按照薪资从高到低独立编号。

• 每个分组的编号都从1重新开始，不会累加。
• 这里有个容易疏忽的点：即使写了PARTITION BY，ORDER BY也还是必须的，否则照样会报错。

ORDER BY 在查询末尾会影响 ROW_NUMBER 的结果

这个问题很隐蔽。SQL的执行顺序决定了，SELECT子句（包括计算ROW_NUMBER()）是在查询末尾的ORDER BY之前完成的。

这意味着什么？假设你在OVER里按name排序生成行号，但又在整个查询的最后写了ORDER BY id。那么，行号的值确实是依据name的顺序计算出来的，但最终结果集展示的顺序，却是按照id来排的。这样一来，你看到的行号顺序和行的物理顺序就对不上了，感觉像是“乱序”。

• 行号的生成逻辑，只由OVER子句内部的ORDER BY决定。
• 查询末尾的ORDER BY，只负责最终结果的展示顺序，不会改变已经生成好的行号值。
• 调试时如果发现行号不对劲，可以尝试先去掉查询末尾的ORDER BY，看看行号本身是否符合预期。

性能敏感场景下慎用大偏移量的 ROW_NUMBER

ROW_NUMBER()虽然强大，但在分页这种场景下，尤其是大偏移量时，性能可能成为瓶颈。想想看，如果你要取第100001行（比如每页10条的第10001页），数据库为了生成这个行号，需要先对所有数据进行排序并编号到100001，然后再过滤。这个开销，可比直接使用LIMIT/OFFSET或者基于游标的分页要大得多。

• 如果纯粹是为了分页，优先考虑数据库原生的分页语法，比如PostgreSQL的OFFSET/LIMIT，或者MySQL 8.0+的LIMIT ... OFFSET。
• ROW_NUMBER()更擅长的场景是“带名次的筛选”，例如“找出每个部门薪资前三的员工”。
• 如果确实需要用ROW_NUMBER()来实现复杂分页，务必确保OVER中ORDER BY的列上有索引，这能极大提升排序效率。

总结一下，实际使用ROW_NUMBER()时，最容易出问题的就是两点：一是忘了OVER子句是强制性的，二是混淆了窗口内ORDER BY和查询末尾ORDER BY的不同角色。把这两个关节理顺了，生成行号这事儿就能变得清晰又可靠。