内容摘要：数据库里跑出一个排行榜，前端同事盯着屏幕喊：怎么有两个第三名？我凑过去一看，SQL 里写着 ORDER BY score DESC，后面没接任何处理重复值的逻辑。这大概是每个写过排序的人都会撞上的墙—

数据库里跑出一个排行榜，排序前端同事盯着屏幕喊：怎么有两个第三名？出现我凑过去一看，SQL 里写着 ORDER BY score DESC，相同后面没接任何处理重复值的名次逻辑。这大概是排序每个写过排序的人都会撞上的墙——两个分数相同的用户，谁排前谁排后，出现数据库根本不关心，相同它只保证返回顺序稳定，名次但不会告诉你这个顺序有什么意义。排序

真实业务里，出现这种“并列”往往不是相同 bug，而是名次需求没说清楚。比如游戏天梯榜，排序两个玩家都是出现 5000 分，那他们应该共享第三名的相同位置，还是按达到该分数的时间先后分出高下？前者是标准竞赛排名（也叫密集排名），后者是改良后的加权排名。我见过最粗暴的处理方式，是直接在应用层给重复分数随机打乱顺序，结果用户投诉说“我明明先打到的分数，为什么排后面”。

从实现角度看，SQL 窗口函数提供了三种现成方案。RANK() 会在分数相同时留下空洞：三个人并列第二，下一个就是第五名。DENSE_RANK() 则紧挨着排，并列第二后直接是第三。ROW_NUMBER() 最狠，完全无视并列，硬给每个记录分配唯一序号——但这样并列的两个人里，谁拿第二谁拿第三，取决于数据库的物理存储顺序，这玩意儿换个索引就可能变。

有意思的是，业务方往往自己都没想清楚要哪种。我曾给一个电商运营团队做活动榜单，他们要求“按销售额排名，并列就按退款率低的优先”。这其实已经跳出了纯排序范畴，变成多条件排序。但更常见的场景是：用户根本不关心并列名次，他们只想知道自己是不是前十。这时候用 DENSE_RANK 反而更友好——第 11 名看到自己前面有 10 个人，哪怕实际有 15 个用户分数高于他，因为其中有 5 个并列第三，他依然能挤进“前十”的感知范围。

还有个容易踩的坑是分页。如果用 RANK 排序后做 LIMIT 分页，每页条数固定，但并列记录可能跨页。比如每页显示 10 条，第三名有 3 个人，那第二页开头会突然冒出两个“第三名”，用户看着像数据错乱。解决思路是排序时加一个唯一性兜底键——比如用户 ID 或者注册时间——但这样一来，并列名次又变味了，因为最终顺序里总有人先有人后。

我自己的习惯是，先问清楚这个排名是给人看的还是给机器算的。给人看的榜单，用 DENSE_RANK 加“并列”标识，前端展示“3（并列）”最直观。给算法或奖励发放用的，直接用 ROW_NUMBER 保证每个记录有唯一名次，避免后续处理时因为并列导致奖励重复或遗漏。至于那种“既要又要”的需求——既要并列名次又要唯一顺序——那本质上就是两个字段的事：一个显示名次，一个显示排序权重，分开存，别混在一起。

说到底，rank 排序的相同名次问题，技术实现十分钟能搞定，真正的复杂度全在业务定义上。下次再遇到“为什么有两个第二”，先别急着改代码，反问一句：你希望这两个第二名的奖品怎么分？答案往往比排序算法本身更精彩。