rank() 并列同名且跳号是规范行为，因按“组内位置+已占位数”计算；如分数95三人并列第1，则92分排第4；需配合over子句，支持partition by分组和nulls last等显式控制。
为什么 RANK() 会把相同值排成并列，还跳号？
RANK() 的设计就是“并列则同名，同名后跳过后续序号”。比如三个用户分数都是 95，RANK() 给他们全打 1，下一个分数（比如 92）就直接是 4——中间的 2 和 3 被跳过了。这不是 bug，是规范行为，源于它按“组内位置 + 已占位数”计算。
常见错误现象：RANK() OVER (ORDER BY score DESC) 返回 1,1,1,4,5，有人误以为是数据或语法错了，其实只是没理解它的语义。
- 适用场景：榜单展示需强调“并列第一/第二”，且接受排名不连续（如竞赛颁奖、考试名次公示）
- 对比
DENSE_RANK()：它并列后不跳号（1,1,1,2,3），ROW_NUMBER()则强制不并列（1,2,3,4,5） - 性能影响：三者执行计划几乎一致，无显著差异；选择只取决于业务语义
RANK() 必须配合窗口子句，否则报错
单独写 RANK() 会触发类似 ERROR: window function requires an OVER clause 的错误。它不是普通聚合函数，不能脱离 OVER 存在。
实操建议：
- 必须写全
RANK() OVER (ORDER BY ...)，括号不可省略 - 排序字段可多列：
RANK() OVER (ORDER BY dept_id, salary DESC)，先按部门分组内排序 - 加
PARTITION BY实现分组内独立排名：RANK() OVER (PARTITION BY dept_id ORDER BY salary DESC) - ORDER BY 里用
NULLS LAST或NULLS FIRST显式控制空值位置（尤其 PostgreSQL / Oracle；MySQL 8.0+ 支持，但默认行为因版本而异）
处理 NULL 值时，RANK() 的排序结果容易误判
不同数据库对 NULL 在 ORDER BY 中的默认位置不同：PostgreSQL 默认 NULLS LAST，Oracle 默认 NULLS FIRST，MySQL 8.0+ 默认 NULL 排最前。这会导致同一 SQL 在不同环境排名顺序不一致。
例如：RANK() OVER (ORDER BY bonus DESC)，如果某行 bonus 是 NULL，它可能被排成第 1 名（Oracle），也可能被排到最后（PostgreSQL），而你根本没意识到。
- 安全做法：始终显式声明
NULLS LAST（多数业务希望空值排末尾） - 示例：
RANK() OVER (ORDER BY bonus DESC NULLS LAST) - 测试时务必用含
NULL的数据验证，别只测非空样本
和 GROUP BY 混用时，RANK() 不会自动去重
有人想“每个部门取 Top 3”，于是写 SELECT dept_id, RANK() OVER (...) AS rk FROM emp GROUP BY dept_id —— 这会报错，因为 RANK() 是窗口函数，不能和 GROUP BY 直接混用，且 GROUP BY 后未聚合的列也不合法。
正确路径只有两种：
- 用子查询或 CTE 先算排名，再外层过滤：
SELECT * FROM (SELECT dept_id, name, salary, RANK() OVER (PARTITION BY dept_id ORDER BY salary DESC) AS rk FROM emp) t WHERE rk
- 用
QUALIFY（仅支持 BigQuery / Snowflake / Teradata）：SELECT dept_id, name, salary FROM emp QUALIFY RANK() OVER (PARTITION BY dept_id ORDER BY salary DESC) - 注意：不能用
HAVING过滤窗口函数结果，HAVING只能作用于GROUP BY的聚合结果
实际写的时候，最容易被忽略的是 NULL 在排序中的隐式行为，以及误以为 RANK() 能直接进 GROUP BY 查询。这两点一错，结果就离谱，而且不容易一眼看出来。
