SQL中DENSE_RANK为何比RANK更符合业务排名逻辑

在日常数据分析工作中，一个常见的困惑是：当业务人员拿着报表询问“为什么Top 3里多了一个人？”时，如果SQL查询使用了RANK()函数，这种疑问几乎难以避免。问题的根源在于RANK()跳号导致排名不连续。

DENSE_RANK() 更符合多数业务排名逻辑，因为它不跳号 —— 排名数字连续、可预期，直接对应“第几档”或“第几级”的业务语义。因此，在需要按档位划分排名的场景下，DENSE_RANK() 是更优的选择。

查“Top 3”时，RANK() 可能漏数据

举个例子，假设销售额数据为 [100, 100, 90, 85, 80]，RANK() 的结果是 [1, 1, 3, 4, 5]。如果使用 WHERE rank <= 3 来筛选，只会返回前三行（两个 100 和一个 90），看起来似乎没问题。

但数据稍微变化，比如变成 [100, 100, 95, 95, 80]，RANK() 的结果就会变成 [1, 1, 3, 3, 5]。此时 rank <= 3 会返回前四行（两个 100 加两个 95），但如果你写的是 rank = 3，它代表的其实是“第三档”，而不是“第三名”。业务上想取“前三档”，RANK() 的 3 却在编号上直接跳过了 2，语义彻底断裂。

与之对比：

• DENSE_RANK() 在相同数据下输出 [1, 1, 2, 2, 3]，使用 dense_rank <= 3 可以稳定覆盖全部三档，毫无歧义。
• 在报表中，如果定义为“A档（第1名）、B档（第2名）、C档（第3名）”，那么 DENSE_RANK() 的输出天然匹配这个映射关系。
• 而 RANK() 的 1,1,3 很容易让业务人员追问：“第2名去哪了？”——这不是数据错误，而是函数语义与业务理解之间的错位。

DENSE_RANK() 的 PARTITION BY 行为更可控

再来看分组排名的场景。按部门分组时，DENSE_RANK() OVER (PARTITION BY dept_id ORDER BY salary DESC) 每个部门都从1开始、连续编号，哪怕某部门只有两人并列第一，另一部门有五人分四档，各组内的档位数仍然是1→2→3…，跨部门对比时一目了然。

RANK() 在小分组里可能直接跳成 1,1,4，导致不同组之间的档位数量完全失真。在做绩效分级（如S/A/B/C）时，必须保证每一档都有编号且不能缺档——DENSE_RANK() 天然支持，而 RANK() 则需要额外补档逻辑，徒增复杂度。

另外，如果排序字段存在重复值，且没有加唯一键兜底（比如只按 score 排序），DENSE_RANK() 的结果依然稳定；虽然 ROW_NUMBER() 可能每次执行顺序不同，RANK() 虽然相对稳定，但档位断层的问题不会消失。

别在 WHERE 里直接用窗口函数

这一点与选择哪个函数无关，但新手几乎都会踩一次。无论使用 RANK() 还是 DENSE_RANK()，都不能写成：

SELECT * FROM sales WHERE DENSE_RANK() OVER (ORDER BY amount DESC) <= 3;

这条语句会直接报错 —— Invalid use of window function。原因很简单：窗口函数在 SELECT 阶段才被计算，而 WHERE 已经执行完毕。正确的写法必须套一层子查询或 CTE。漏掉嵌套是新手最常犯的错误，一旦出错，很容易让人误以为是 DENSE_RANK() 不可用。

还有一个容易被忽略的细节：如果用了 PARTITION BY 却漏写了，比如本该按 region 分组，却只写了 ORDER BY sales，结果就变成全表统一排名，业务逻辑全歪。

真正值得注意的点是，跳不跳号本身并不影响函数的性能，也不改变语法。但它直接决定了你写的 WHERE dense_rank <= N 是不是真的能代表“前 N 档”——而绝大多数业务要的不是“名次”，而是“档位”。这就好比比赛颁奖，领奖台上站的是三个人，但排第四的那个人不该被问“你为什么会和第三名出现在同一个名次里？”