RANK()跳过后续名次（如1,1,3），DENSE_RANK()不跳（如1,1,2），核心在于前者按“并列行数+当前名次”计算下一名次，后者恒按“当前名次+1”递进，本质是业务语义是否允许排名空档。
为什么 RANK() 和 DENSE_RANK() 会跳过后续排名？
因为它们本质是按「组内排序位置」而非「连续序号」生成的。当多行值相同时，RANK() 给它们分配相同名次，但下一名次 = 当前名次 + 并列行数；DENSE_RANK() 同样给并列行相同名次，但下一名次 = 当前名次 + 1。
比如成绩 [95, 95, 90]：
- RANK() → [1, 1, 3]（跳过 2）
- DENSE_RANK() → [1, 1, 2]（不跳）
这不是 bug，是设计行为。如果你要的是「不跳且唯一编号」，得用 ROW_NUMBER()，但它不处理并列——哪怕值相同也会强制分出 1/2/3。
在 ORDER BY 中混用多个字段时，RANK() 怎么算？
RANK() 和 DENSE_RANK() 的排序逻辑完全依赖 OVER (ORDER BY ...) 子句，和普通 ORDER BY 规则一致：先比第一字段，相等再比第二字段，依此类推。
常见误操作是以为「并列只看主字段」，其实不是。例如：
SELECT name, subject, score,
RANK() OVER (ORDER BY subject, score DESC) AS rk
FROM scores;这里先按 subject 分组排序，再在每个科目内按 score 降序排。如果两个学生科目不同，哪怕分数一样，也不会并列。
- 想跨科目全局排名？把
ORDER BY改成ORDER BY score DESC - 想先按总分、再按姓名去重并列？写成
ORDER BY SUM(score) DESC, name（配合 GROUP BY） - 注意 NULL 默认排最前（ASC）或最后（DESC），必要时加
NULLS LAST（PostgreSQL）或用COALESCE(score, 0)（通用）
MySQL 8.0+ 和 PostgreSQL 中的窗口函数兼容性差异
两者都支持 RANK() 和 DENSE_RANK()，但细节有坑：
- MySQL 不支持
NULLS FIRST/LAST，想控制 NULL 位置得用IFNULL()或CASE WHEN转义 - PostgreSQL 允许在
OVER里写PARTITION BY+ORDER BY+ 窗口帧（如ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW），但RANK()忽略帧定义——它只认PARTITION BY和ORDER BY - SQL Server 同样忽略帧，且对
ORDER BY中的表达式限制更严（比如不能直接用LEN(name)，得包一层子查询或 CTE）
所以别在 OVER 里写复杂计算字段，除非你确认目标数据库支持。稳妥做法是先在 SELECT 列表中算好别名，再在 ORDER BY 里引用该别名（多数数据库支持）。
实际业务中选 RANK 还是 DENSE_RANK？关键看下游怎么用
很多同学卡在「哪个更‘正确’」，其实取决于下游系统是否接受「断号」：
- 做 Top N 报表（如“取前 5 名”），用
RANK()可能返回 7 行（因为第 4、5 名并列，挤进来了第 6、7 行），而DENSE_RANK()更贴近「真正前 5」的语义 - 对接 BI 工具（如 Tableau、Superset），它们常把排名当维度拖拽，
DENSE_RANK()产生的连续整数更友好，RANK()的空缺可能引发过滤异常 - 做积分榜或排行榜 API 返回值，用户看到「第 1、第 1、第 3」容易困惑，而「第 1、第 1、第 2」更符合直觉
真正容易被忽略的是：一旦用了 PARTITION BY，两种函数的「并列逻辑」只在各自分区内生效。跨分区不比较，哪怕值一样也重新从 1 开始排——这点在写用户分城市榜单时特别关键，别误以为全国同分就该同名次。
