MySQL ROW_NUMBER 遇到并列值怎样稳定排序

MySQL 的 ROW_NUMBER() 遇到并列值时，不会给并列行相同编号，而是继续分配不同的行号。如果窗口里的 ORDER BY score 只能比较出“分数相同”，却不能决定两行谁先谁后，那么这两行的相对顺序就没有被完整定义。

稳定写法是把业务排序列和唯一键一起放进窗口排序：例如 ORDER BY score DESC, submitted_at ASC, id ASC。前面的列表达业务优先级，最后的唯一 id 负责在所有条件都相同时收口。这样取每组前几名、做分页或生成导出序号时，结果才有可复现的顺序。

官方文档：https://dev.mysql.com/doc/refman/8.4/en/window-function-descriptions.html

并列值为什么会让 ROW_NUMBER 结果不稳定

窗口函数先按 PARTITION BY 把行分组，再按窗口里的 ORDER BY 定义分区内部的排序。按照 MySQL 8.4 手册，ROW_NUMBER() 返回当前行在分区中的编号；如果没有窗口 ORDER BY，分区内没有处理顺序，编号就是非确定的。

即使写了 ORDER BY score DESC，相同分数的行仍然属于 peers。ROW_NUMBER() 必须给每行一个不同的数字，所以它会把同分行排成某个相对顺序，但 score 本身没有说明这两行应该谁先出现。不要把一次查询中看到的编号顺序当成业务契约。

-- 只按分数排序：相同 score 的两行没有第二排序条件
WITH ranked AS (
    SELECT
        id,
        group_id,
        score,
        ROW_NUMBER() OVER (
            PARTITION BY group_id
            ORDER BY score DESC
        ) AS rn
    FROM exam_result
)
SELECT id, group_id, score, rn
FROM ranked
WHERE rn 

这段查询适合说明“分组取前三名”的形状，但不适合要求结果长期稳定的导出或分页。若 group_id=10 下有两条 score=98 的记录，二者会拿到不同的 rn，可是谁是 2、谁是 3，不应由存储访问路径或偶然的中间排序决定。

把排序条件补成唯一顺序

要让编号稳定，关键不是给 ROW_NUMBER() 再套一层查询，而是让窗口的排序表达式形成完整的优先级链。先按分数决定主要顺序，再按提交时间处理业务上的先后，最后用主键 id 解决时间也相同的情况。

-- 先按分数，再按提交时间，最后用唯一 id 收口
WITH ranked AS (
    SELECT
        id,
        group_id,
        score,
        submitted_at,
        ROW_NUMBER() OVER (
            PARTITION BY group_id
            ORDER BY score DESC, submitted_at ASC, id ASC
        ) AS rn
    FROM exam_result
)
SELECT id, group_id, score, submitted_at, rn
FROM ranked
WHERE rn 

这里的含义是：同一组里分数更高者优先；分数相同则提交更早者优先；分数和提交时间都相同，则较小的唯一 id 优先。只要这三个字段组合可以把候选行排成唯一顺序，rn 就不再依赖“这次恰好先读到哪一行”。

如果业务要取“每组最新三条”，方向可以反过来写成 score DESC, submitted_at DESC, id DESC。不要只把 id 放到最前面，因为那会让主键顺序覆盖分数或时间的业务含义。

时间相同、NULL 和最终展示顺序要分开处理

时间戳不是天然唯一键

很多表把 created_at 当成第二排序列，但同一批写入、批量导入或低精度时间列都可能产生相同时间。它可以表达“先按时间”，却不能独自完成稳定排序。仍然要把非空、唯一的主键放到最后。

NULL 的方向要写清楚

MySQL 文档说明，窗口 ORDER BY 中升序时 NULL 排在前面，降序时排在后面。如果业务希望“没有时间的记录永远排最后”，可以把规则显式写出来，再使用时间和主键收口：

-- 把缺失时间统一放在最后，再按时间和 id 排序
ROW_NUMBER() OVER (
    PARTITION BY group_id
    ORDER BY
        (submitted_at IS NULL) ASC,
        submitted_at ASC,
        id ASC
) AS rn

括号里的布尔表达式先把 NULL 分到后面；它解决的是业务排序规则，不代替最后的唯一键。

窗口排序不等于结果集排序

窗口里的 ORDER BY 只决定函数如何给分区内的行编号。它不会自动保证最终返回的行按这个顺序显示。尤其是外层还有筛选、分页或连接时，应该显式写结果集的 ORDER BY，通常按分组键和生成的 rn 排列。

ROW_NUMBER、RANK 和 DENSE_RANK 不是一回事

如果业务的规则是“并列者共享名次”，就不要强行用 ROW_NUMBER()。MySQL 8.4 将 peers 视为排序表达式相等的行，三种函数的差异可以用下面的表快速判断：

即使选择 RANK() 或 DENSE_RANK()，窗口的排序列仍然要符合业务语义。稳定排序主要解决“同分行谁先后”的问题；并列排名则解决“同分行是否共享名次”的问题，两个决策不要混为一个参数。

生产查询上线前的排序检查清单

• 窗口里是否写了 ORDER BY？没有它时，分区没有处理顺序。
• 主要排序列表达的是业务优先级，还是只是为了让结果看起来有序？
• 所有排序列相同的两行，最后是否还有一个非空唯一键收口？
• 时间列可能相同吗？批量写入和时间精度不足时，默认按“可能相同”处理。
• NULL 的前后位置是否符合业务规则？需要时显式加布尔表达式。
• 外层是否有自己的 ORDER BY？窗口顺序不能替代最终展示顺序。
• 分页或增量导出是否复用了同一组排序列？不要只依赖生成的 rn 而忽略原始唯一键。

一句话收尾：ROW_NUMBER() 可以编号并列行，但不会替你猜出并列时的业务顺序。把排序写成“业务字段优先，唯一键最后”，再在外层明确展示顺序，结果才适合稳定的报表、分页和导出。

相关问题

只写主键 ASC 能不能保证稳定？

能保证唯一，但可能改变业务顺序。主键通常应该作为最后的收口列，而不是取代分数、时间等主要排序条件。

ROW_NUMBER 能不能让相同分数得到相同名次？

不能。需要并列名次时使用 RANK() 或 DENSE_RANK()，具体选择取决于后续名次是否跳号。

为什么窗口里有 ORDER BY，结果打印顺序仍然变了？

因为窗口排序只服务于窗口函数，最终结果集仍由外层查询的 ORDER BY 决定。