RANK()遇重复值跳过后续名次（如1,1,3,4），DENSE_RANK()则连续不跳（如1,1,2,3），核心在于是否保留排名序列的连续性。
RANK() 和 DENSE_RANK() 的核心区别就一条：遇到相同值并列时，RANK() 跳过后续名次，DENSE_RANK() 不跳 —— 这直接决定你查出来的排名数字是否“连续”。
为什么 RANK() 会跳名次
RANK() 的逻辑是“当前行前面有多少个更优的值 + 1”，但这个“更优”是按去重后计数的。比如分数 [100, 100, 90, 80, 80] 降序排：
前两行都是 100 → 都算第 1 名；
第三行 90 比它前面所有值都小，而前面只有 1 个唯一值（100），所以排名 = 1 + 1 = 2？不对 —— 实际是 3。
因为 RANK() 真正计算的是：比当前值大的**不同值个数** + 1。比 90 大的不同值有 {100}，共 1 个 → 排名 = 1 + 1 = 2？还是不对。
准确说：RANK() 给每个唯一值分配一个名次，然后把相同值的行都塞进那个名次里，下一个唯一值的名次 = 上一个名次 + 它前面已占用的名次数。
所以 100 占了名次 1，90 就得从名次 3 开始（跳过 2）。
常见错误现象：
• 查“销售额排名第 2 的产品”，用 RANK() 却查不到结果 —— 因为实际第 2 名被跳过了
• 导出报表时发现排名序列是 1, 1, 3, 4, 4, 6，业务方质疑“怎么没有第 2 名和第 5 名？”
使用场景：
• 需要强调“超越了多少个不同梯队”时（例如奥运奖牌榜，两个金牌后银牌就是第三名，不叫第二名）
• 做历史位次对比，关注的是“跨越了多少个门槛值”而非单纯顺序
DENSE_RANK() 怎么保证连续
DENSE_RANK() 的逻辑更直觉：排好序后，给每个**首次出现的值**分配一个递增整数，重复值复用同一个数，下个新值接着上一个数继续加 1。
对同样数据 [100, 100, 90, 80, 80]：
100 第一次出现 → 分配 1
第二个 100 → 还是 1
90 第一次出现 → 分配 2
第一个 80 → 分配 3
第二个 80 → 还是 3
参数差异：
• 两者语法完全一致：RANK() OVER (ORDER BY score DESC) 和 DENSE_RANK() OVER (ORDER BY score DESC)
• 唯一区别就是函数名，其他部分包括 PARTITION BY、排序方向、NULL 处理都无差异
性能影响：
• 在绝大多数数据库（PostgreSQL、SQL Server、Oracle、MySQL 8.0+）中，两者执行计划和耗时几乎无差别
• 不会因为“连续”或“跳跃”逻辑带来额外计算开销 —— 底层都是基于排序后的扫描计数
什么时候必须用 DENSE_RANK() 而不是 RANK()
当业务语义要求“名次即位置序号”时，DENSE_RANK() 是唯一安全选择：
- 查“各班级数学成绩前 3 名的学生”——如果用
RANK()，某班出现两个并列第一，第三名就变成第 4 名，WHERE rank 会漏掉真正的第三优者 - 生成排行榜 API，前端按“第 1 名、第 2 名、第 3 名…”渲染，不能接受中间缺号
- 做分位计算，比如“进入前 10%”需要按
DENSE_RANK() / COUNT(*)算比例，跳号会导致分母失真 - 与外部系统对接时，对方约定“排名为整数且连续”，否则解析失败
容易踩的坑：
• 误以为 RANK() “更精确”——其实只是语义不同，没有精度高低之分
• 在分页场景混用：比如用 RANK() 取 top 10，结果因跳号只返回 8 行，还以为数据丢了
• 忽略 NULL 值默认排序行为（多数数据库把 NULL 排在最前或最后，会影响并列判断）
ROW_NUMBER() 和它们的根本区别在哪
ROW_NUMBER() 不是排名函数，是**行号生成器**：
• 它完全不关心值是否重复，只按排序后物理顺序硬编 1, 2, 3…
• 所以哪怕所有分数都是 100，ROW_NUMBER() 也会给出 1, 2, 3, 4…
这意味着：
• 如果你要“取每科成绩最高的那个学生（仅一人）”，用 ROW_NUMBER() + WHERE rn = 1 是对的
• 但如果要“取每科成绩并列第一的所有学生”，就必须用 RANK() 或 DENSE_RANK()，再配合 WHERE rank = 1
真正复杂的地方在于：很多业务需求表面说“排名”，实际要的是“分组内唯一序号”或“去重后梯队序号”，得先厘清这句话到底想表达什么 —— 是“第几个出现的”，“第几个不同的值”，还是“第几个梯队”。选错函数，后面所有分析都偏了。
