在日常数据分析工作中，一个常见的困惑是：当业务人员拿着报表询问“为什么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 档”——而绝大多数业务要的不是“名次”，而是“档位”。这就好比比赛颁奖，领奖台上站的是三个人，但排第四的那个人不该被问“你为什么会和第三名出现在同一个名次里？”
