选 rank() 还是 dense_rank() 取决于是否接受排名空档：rank() 并列后跳号（如两个第1名后为第3名），dense_rank() 并列后不跳号（两个第1名后为第2名），两者仅在跳号逻辑上不同，适用场景由业务对“名次”的定义决定。
直接说结论：选 RANK() 还是 DENSE_RANK()，取决于你是否能接受排名中间出现“空档”。如果并列后要跳过序号（比如两个第1名，下一个是第3名），用 RANK()；如果并列后必须紧接下一个整数（两个第1名，下一个是第2名），就用 DENSE_RANK()。
相同分数时，RANK() 会跳号，DENSE_RANK() 不会
这是最常踩坑的地方。比如成绩都是 90 分的两人，在 RANK() 下都得第1名，但下一个 89 分的人就是第3名；而 DENSE_RANK() 下，89 分的人是第2名。
-
RANK()：相同值 → 同排名 → 下一排名 = 当前排名 + 相同值个数（即跳过） -
DENSE_RANK()：相同值 → 同排名 → 下一排名 = 当前排名 + 1（不跳） - 两者都不依赖数据本身是否唯一，只看
ORDER BY字段的重复情况
业务场景决定函数选择，不是“哪个更高级”
没有优劣，只有适配。关键看下游怎么理解这个“名次”：
- 体育比赛、考试总分榜这类允许并列且强调“击败了多少人”的场景，用
RANK()更符合直觉（第1名有两个，第3名意味着前面有2人比他高） - 薪资档位、会员等级、产品评分区间这类需要连续阶梯的场景，用
DENSE_RANK()更合理（档位只有5级，不能因为有人并列就变成6级） - 千万别在报表里混用：同一张表里同时展示
RANK()和DENSE_RANK()的结果，却不加说明，容易引发业务方质疑
注意 PARTITION BY 对两者的同步影响
无论用哪个函数，只要加上 PARTITION BY，排名就重置为每组独立计算。这点两者行为完全一致，但容易被忽略：
-
RANK() OVER (PARTITION BY department ORDER BY salary DESC)：每个部门内单独排名，且各自跳号 -
DENSE_RANK() OVER (PARTITION BY department ORDER BY salary DESC)：每个部门内单独排名，且各自连续 - 错误写法：
ORDER BY salary DESC写成ORDER BY salary ASC，会导致排名倒置，但函数逻辑不变
真正容易被忽略的点是：RANK() 和 DENSE_RANK() 都不保证原始行顺序——如果 ORDER BY 字段存在大量重复，数据库可能每次返回不同行的排列顺序，除非你额外加一个确定性排序字段（比如 ORDER BY salary DESC, id ASC）。
