成绩排名应使用rank()而非dense_rank()，因rank()通过留空体现名次断层（如1,1,3,4），准确反映实际分差与业务逻辑；dense_rank()连续编号（1,1,2,3）会掩盖差距，属常见误用。

不是“更适合”，而是“适用场景不同”——用DENSE_RANK()做成绩排名，反而常出错。

成绩排名到底要解决什么问题

成绩排名的核心诉求通常是：体现真实名次层级，比如“两个并列第一，下一个就是第三名”，这符合颁奖、升学、淘汰等业务逻辑。RANK()正是为此设计的：它把相同分数看作一个“段”，段内共享名次，段与段之间留空档，准确表达差距断层。

常见错误现象：RANK()返回 1, 1, 3, 4，有人误以为“漏了第2名”；其实它在说：前两人同属第一段，第三名是第二段的起始，中间没“第二段”的人——这恰恰是成绩排名需要的语义。

而DENSE_RANK()给出 1, 1, 2, 3，它只关心“值变没变”，不体现段落断层。在成绩单上强行连续编号，会模糊实际分差，比如95分和90分被标为2和3，看似紧凑，实则掩盖了5分落差带来的名次实质变化。

为什么有人觉得DENSE_RANK“更顺眼”

这种错觉往往来自两个混淆：

• 把“展示界面需要连续数字”当成“业务规则要求连续名次”——UI可以做映射（如后端传rank_val=3，前端显示“第三名”），没必要让SQL牺牲语义去迁就显示
• 误用WHERE dense_rank 查“前三名”，结果因大量并列返回几十行——这不是<code>DENSE_RANK()的问题，是没理解它根本不控制行数，只负责分档

真正需要连续编号的场景，其实是内部绩效分级（如S/A/B/C档）、销售梯队划分——这些业务本就不强调“第几”，只关心“属于哪一档”，DENSE_RANK()才匹配。

实战中RANK()必须注意的坑

RANK()本身没问题，但容易因写法错误导致结果失真：

• 漏写PARTITION BY：比如按科目排名却没加PARTITION BY subject，结果变成全校统一排序
• ORDER BY方向写反：想要“高分排第1”却忘了加DESC，导致最低分得rank = 1
• 在WHERE里直接引用RANK()：会报Invalid use of window function，必须套子查询或CTE
• NULL值处理不一致：PostgreSQL默认NULLS FIRST，MySQL默认NULLS LAST，若成绩字段含NULL，排名位置可能跨库不一致

真正容易被忽略的一点

RANK()和DENSE_RANK()都不删行、不合并、不过滤——它们只是给每行打一个标签。决定“谁上榜”“取几人”的，永远是外层的WHERE、QUALIFY或业务逻辑。指望函数自己搞定去重或截断，是绝大多数排名事故的起点。