成绩排名应使用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或业务逻辑。指望函数自己搞定去重或截断，是绝大多数排名事故的起点。
