dense_rank()生成连续排名是因为相同值共享同一排名且后续排名不跳号。例如三人同为95分均排第1，下一名为第2；而rank()会跳至第4，row_number()则强制递增无重复。
为什么 DENSE_RANK() 生成的排名是连续的
DENSE_RANK() 的核心行为是：相同值共享同一个排名，且后续排名不跳号。这和 RANK()（跳号）和 ROW_NUMBER()（无重复、强制递增）有本质区别。比如三个人分数都是 95，DENSE_RANK() 给他们全打 1，下一名得 2；而 RANK() 也会给 1，但下一名是 4（因为占了三个位置）。
它适合需要“并列不空档”的业务场景，比如榜单、绩效分级、考试名次公示——你不会想看到“第1名、第1名、第1名、第4名”这种断层显示。
基本语法和必须注意的 ORDER BY
DENSE_RANK() 是窗口函数，必须搭配 OVER() 子句，且 ORDER BY 是强制项，漏写会报错：Window function requires an OVER clause。
- 正确写法：
SELECT name, score, DENSE_RANK() OVER (ORDER BY score DESC) AS rank_num FROM students; - 不能只写
OVER()，也不能把ORDER BY放在外部查询里代替窗口内的排序 - 排序方向影响结果：用
DESC得高分优先（常见），用ASC则低分排前面 - 支持多列排序：
OVER (ORDER BY dept ASC, salary DESC)，先按部门升序，同部门内按薪资降序排名
和 RANK()、ROW_NUMBER() 混用时的典型陷阱
三者常被放在一起对比，但实际混用容易出逻辑错误。比如有人想“先去重再排名”，试图用 ROW_NUMBER() 套 DENSE_RANK()，这是无效的——窗口函数不能嵌套调用。
- 错误示例：
DENSE_RANK() OVER (ORDER BY ROW_NUMBER() OVER (ORDER BY score))→ 语法错误，ROW_NUMBER()不能直接当ORDER BY的表达式 - 真正要去重后排名？应先用
GROUP BY或DISTINCT预处理数据，再对结果集应用DENSE_RANK() - 分区（
PARTITION BY）下行为一致：比如按部门分组排名，每个部门内仍保持连续，但不同部门间排名独立（部门A的第1名 ≠ 部门B的第1名） - NULL 值默认排最前（
ASC）或最后（DESC），若需统一处理，显式加NULLS LAST或NULLS FIRST（PostgreSQL/Oracle 支持；MySQL 8.0+ 不支持该子句）
MySQL 8.0+ 和 PostgreSQL 的兼容性细节
虽然标准 SQL 定义了 DENSE_RANK()，但老版本 MySQL（FUNCTION xxx.DENSE_RANK does not exist。
- 确认版本：
SELECT VERSION();—— 必须 ≥ 8.0.2 才稳定支持 - PostgreSQL 从 8.4 开始支持，行为标准，
PARTITION BY和ORDER BY用法与 SQL 标准一致 - SQLite 3.25+ 支持，但不支持
FRAME子句（不过DENSE_RANK()本身不需要） - SQL Server 全版本支持，但旧版（2005+）语法一样，无需额外配置
跨数据库迁移时，别只测功能，一定要验证 NULL 处理和 PARTITION BY 边界行为——比如某行刚好卡在分区边界，不同引擎对“排序稳定性”的实现略有差异。
