dense_rank()适合积分等级划分，因其保证同分同级且等级连续（如1,2,2,3），而rank()跳号、row_number()无视同分；需配合order by score desc使用，并先过滤再排名以确保准确性。
为什么 DENSE_RANK() 比 RANK() 更适合积分等级划分
因为积分相同必须同等级，且后续等级不能跳号——比如两个用户并列第2名后，下一名必须是第3名，而不是第4名。RANK() 会跳号（如 1,2,2,4），而 DENSE_RANK() 严格连续（1,2,2,3）。这是“无间断”的核心保障。
常见错误是误用 ROW_NUMBER()：它给每行独立编号，哪怕积分完全一样也会分出 1,2,3… 完全违背“同分同级”原则。
- 适用场景：用户积分榜、商品销量分级、考试成绩段位划分
- 注意：
DENSE_RANK()是窗口函数，必须配合OVER子句，不可直接用于WHERE或GROUP BY - 排序方向决定等级高低：按
score DESC才能让高分得低等级数字（如第1名）
基础写法：按积分降序生成连续等级
假设表 users 有字段 user_id 和 score，直接加一列等级：
SELECT user_id, score, DENSE_RANK() OVER (ORDER BY score DESC) AS rank_level FROM users;
结果中，最高分用户为 rank_level = 1，并列最高分者都得 1；次高分无论几人，统一为 2 —— 真正无间隙。
- 别漏写
DESC：默认升序（ASC），会导致最低分排第1，逻辑反了 - 多个排序键可加：如
ORDER BY score DESC, created_at ASC，解决同分时按注册时间早优先 - MySQL 8.0+、PostgreSQL、SQL Server、Oracle 都支持；SQLite 不支持窗口函数
结合条件过滤或分组再排名
如果只对某类用户（如 status = 'active'）划分等级，**必须先过滤再排名**，否则空占位会影响密集性。错误写法是把 WHERE 放在外部：
-- ❌ 错误：先全量排名再过滤，rank_level 可能不连续 SELECT * FROM ( SELECT user_id, score, DENSE_RANK() OVER (ORDER BY score DESC) r FROM users ) t WHERE status = 'active';
正确做法是在窗口内过滤，或用 CTE 预处理：
-- ✅ 正确：先筛选，再排名 SELECT user_id, score, DENSE_RANK() OVER (ORDER BY score DESC) AS rank_level FROM users WHERE status = 'active';
- 若需按城市分组各自排名，用
PARTITION BY city，但此时各城市内部独立连续，跨城不比较 -
DENSE_RANK()不接受NULL排序值：含score IS NULL的行会被归到最末（或最前，取决于NULLS FIRST/LAST，但并非所有数据库支持该语法）
映射到预设等级名称（如青铜/白银/黄金）
DENSE_RANK() 输出的是数字序号，业务常需转成名称。不要硬编码 CASE WHEN rank_level = 1 THEN '黄金'...，因为等级数量可能变。更稳的方式是用查找表：
WITH ranked AS ( SELECT user_id, score, DENSE_RANK() OVER (ORDER BY score DESC) AS dr FROM users ) SELECT r.user_id, r.score, l.level_name FROM ranked r LEFT JOIN level_bounds l ON r.dr BETWEEN l.min_rank AND l.max_rank;
其中 level_bounds 表存：min_rank、max_rank、level_name（如 1–10 → 黄金）。这样增减等级只需改配置表，不动 SQL 逻辑。
- 避免用
dr 这类单边条件：万一未来删掉前5名，原第6名变成第1名，但硬编码的“<li>如果等级边界由积分值定义（如 score >= 9000 → 黄金），那就不用 <code>DENSE_RANK()，直接CASE WHEN score >= 9000 THEN '黄金'—— 两种思路适用不同场景
实际用时最容易忽略的是：排名依据字段存在 NULL 或数据类型隐式转换（比如 score 是字符串），导致排序结果意外，DENSE_RANK() 再准也没用。先 SELECT DISTINCT score FROM users ORDER BY score DESC 看一眼真实分布，比调半天函数更省时间。
