无需修改原ORDER BY子句，求ROW_NUMBER()替代方案获取行位置

嘿，这个问题确实戳中了很多开发者的痛点——既要拿到行号做后续处理，又不想动那些被多个模块共享的复杂核心查询，完全能理解你的顾虑！

先直接给你结论：绝大多数主流关系型数据库并没有提供可以直接获取当前结果集行位置的内置变量或函数。这是因为SQL本质是基于集合的查询语言，结果集在没有明确指定ORDER BY的情况下，行的“位置”是不确定的（数据库可以按任意顺序返回数据），而ROW_NUMBER()必须依赖ORDER BY子句才能生成稳定、可预期的行号。

不过别担心，我们有不用修改原查询代码的变通方案：

最通用稳妥的方案：嵌套子查询/CTE包装原查询 #

你完全不需要改动原查询的任何代码，只需要把它整个作为子查询或者CTE（公共表表达式）嵌套在外层，然后在外层添加ROW_NUMBER()即可。举个例子：

-- 外层查询负责生成行号，完全不碰原查询代码
SELECT *, 
       ROW_NUMBER() OVER(ORDER BY /* 这里复制原查询的ORDER BY字段，保证行号排序和原结果一致 */) AS RN
FROM (
    -- 这里直接粘贴原查询的完整代码，一字不改
    SELECT ... FROM ... JOIN ... WHERE ... ORDER BY ...
) AS wrapped_result;

这个方法的好处是：

• 原查询的代码完全保留，其他模块的使用不受任何影响
• 行号的排序逻辑和原查询完全一致，保证结果的正确性
• 兼容所有支持窗口函数的数据库（SQL Server、PostgreSQL、MySQL 8+、Oracle等）

如果你的数据库是MySQL 5.x（不支持窗口函数），可以用会话变量来模拟：

-- 先初始化会话级变量
SET @rownum = 0;

-- 同样嵌套原查询，在外层递增变量得到行号
SELECT *, (@rownum := @rownum + 1) AS RN
FROM (
    SELECT ... FROM ... JOIN ... WHERE ... ORDER BY ...
) AS wrapped_result;

不过这种方法依赖会话变量，在并发场景下可能有风险，优先推荐窗口函数的方案。

为什么不能直接用“行位置”变量？ #

再补充解释一下背后的逻辑：SQL标准里没有定义“结果集行位置”这种概念，因为集合是无序的。只有当你通过ORDER BY明确指定排序规则后，行的顺序才是确定的，ROW_NUMBER()也正是基于这个确定的顺序来生成行号的。如果真的有一个“行位置”变量，它的值会因为数据库的执行计划、索引使用等因素随时变化，完全不可靠。

所以，嵌套原查询加窗口函数的方案，是目前兼顾代码复用性和结果正确性的最优解。

内容的提问来源于stack exchange，提问作者Álvaro González