dense_rank不跳号是因为它按排序分组后为每组分配递增序号，组内共享、组间+1；而rank依据“前面已出现的不同排名数”计算，重复值导致跳号。
DENSE_RANK 就是专门干这个的——相同值共享一个名次，后续名次不跳号，比如 1, 1, 2, 3, 3, 4，不是 1, 1, 3, 4, 4, 6（那是 RANK 干的事）。
为什么 DENSE_RANK 不跳数字？它和 RANK 的本质区别在哪
DENSE_RANK 按排序分组后，给每组分配一个递增的整数序号，组内所有行共享该序号；下一组直接 +1，不管上一组有多少行。而 RANK 是按“前面已出现多少个不同排名”来算的，所以重复值越多，跳得越狠。
常见错误现象：写了 RANK() OVER (ORDER BY score DESC)，结果看到 95→1、95→1、87→3（中间跳了 2），误以为是 bug——其实是函数选错了。
- 用
DENSE_RANK：相同分数必须紧挨着排，且后续名次连续 - 用
RANK：强调“击败了多少人”，适合排行榜展示“并列第 X 名”但需体现总人数差距 - 用
ROW_NUMBER：纯顺序编号，哪怕分数一样也强制拆开（1,2,3...）
实际写法：ORDER BY 和 PARTITION BY 怎么配才不出错
核心就一句：DENSE_RANK() OVER (ORDER BY 列名 [ASC|DESC])。加 PARTITION BY 是为了分组内独立排名，比如“每个部门内按薪资排名”。
容易踩的坑：
PostgreSQL 18.4 官方 Ubuntu 安装包现已发布，这是目前最新的稳定版本。推荐通过官方 APT 仓库安装：先执行 sudo apt update 更新索引，再运行 sudo apt install postgresql-18 即可完成部署。新版本引入了异步 I/O 子系统，在顺序扫描与 VACUUM 场景下性能提升显著，同时支持 UUID v7 原生生成函数与虚拟生成列。
-
ORDER BY必须写，否则报错window function requires an ORDER BY clause - 如果漏写
DESC，默认升序（从小到大），高分反而排后面 -
PARTITION BY dept_name后，ORDER BY salary DESC是在每个部门内单独算DENSE_RANK，跨部门不连续
示例（学生成绩连续排名）：
SELECT name, score,
DENSE_RANK() OVER (ORDER BY score DESC) AS rank_no
FROM students;
性能与 NULL 值怎么处理
DENSE_RANK 是窗口函数，执行时需对整个结果集排序，数据量大时注意索引——给 ORDER BY 的列建索引能显著提速。
NULL 值默认排在最前（ASC）或最后（DESC），但具体位置依赖数据库配置（NULLS FIRST / NULLS LAST）。如果不控制，可能让 NULL 被排成第 1 名，干扰业务逻辑。
- 显式声明：
ORDER BY score DESC NULLS LAST，确保 NULL 不占有效名次 - 更稳妥的做法：用
CASE WHEN score IS NULL THEN -1 ELSE score END预处理，避免排序歧义 - 别在
WHERE里过滤后再排名——那会改变原始分组结构，导致DENSE_RANK结果不符合预期
真正麻烦的是嵌套场景：比如先按城市分组，再在组内用 DENSE_RANK，同时还要排除某些状态的记录。这时候 PARTITION BY 和过滤时机（WHERE vs FILTER）稍有偏差，排名就会错位——得反复确认数据边界是否和业务定义一致。
