dense_rank()生成连续排名是因为相同值共享同一序号且后续序号不跳过。例如数据[100,100,90]降序排列时结果为[1,1,2]，而rank()为[1,1,3]，row_number()为[1,2,3]；其排名仅依据order by字段值是否相等，与物理顺序无关。
为什么 DENSE_RANK() 生成的排名是连续的
DENSE_RANK() 的核心行为是：相同值共享同一个排名，且后续排名不跳号。这和 RANK()（跳号）与 ROW_NUMBER()（强制唯一递增）有本质区别。比如数据 [100, 100, 90] 按降序排：DENSE_RANK() 给出 [1, 1, 2]；RANK() 是 [1, 1, 3]；ROW_NUMBER() 是 [1, 2, 3]。
它不依赖物理顺序或主键，只看 ORDER BY 子句中表达式的实际值是否相等。
基本语法和必须写的 PARTITION BY + ORDER BY
DENSE_RANK() 必须搭配 OVER() 子句，且 ORDER BY 是强制项；PARTITION BY 可选，但漏写会导致全表统一排序——这在分组内排名时是常见错误。
- 正确写法：
SELECT name, score, DENSE_RANK() OVER (PARTITION BY subject ORDER BY score DESC) AS rank - 错例（没分区）：
DENSE_RANK() OVER (ORDER BY score DESC)→ 所有科目混在一起排，数学 95 和语文 95 会被视为同一名次，但业务上通常要分科独立排名 -
ORDER BY支持多列，如ORDER BY dept ASC, salary DESC，此时先按部门升序，同部门内再按薪资降序
NULL 值怎么处理？ORDER BY 默认排序方向很关键
ORDER BY 中遇到 NULL，不同数据库默认行为不一致：PostgreSQL 和 SQL Server 默认 NULLS LAST，MySQL 8.0+ 默认 NULLS FIRST（但 MySQL 实际仍按传统方式把 NULL 当最小值）。这直接影响 DENSE_RANK() 的结果位置。
- 显式控制更安全：
ORDER BY score DESC NULLS LAST（标准 SQL），或兼容写法：ORDER BY score DESC, id ASC（用非空字段兜底） - 如果业务要求“成绩为空者排最后”，别只写
ORDER BY score DESC，否则在某些引擎里可能排最前 - 测试时建议用含
NULL的小数据集验证，比如插入一条score = NULL记录，观察其DENSE_RANK()输出值
和 RANK()、ROW_NUMBER() 混用容易踩的坑
三者常被同时出现在同一查询中用于对比分析，但逻辑混淆会导致语义错误。例如想“查每科前三名”，误用 ROW_NUMBER() 会把并列第二名中的一人踢出，而 DENSE_RANK() 才真正满足“前三名”业务含义（即最多三人，但允许并列后仍有第三名）。
- 错误过滤条件：
WHERE rn （<code>rn来自ROW_NUMBER()）→ 可能漏掉并列第 2 名的其他人 - 正确做法：
WHERE dr （<code>dr来自DENSE_RANK()）→ 确保所有排名为 1/2/3 的记录都入选 - 性能注意：三个函数开窗逻辑相同，执行计划无差异；但
DENSE_RANK()内部需做值去重计数，大数据量下内存占用略高于ROW_NUMBER()，不过通常可忽略
真正麻烦的是跨数据库移植——Oracle 和 PostgreSQL 行为一致，但旧版 MySQL（DENSE_RANK() 的连续性逻辑就得靠额外判断实现，不是简单替换函数就能解决的。
