RANK()查Top N可能漏数据，因其并列后跳号（如1、2、2、4），导致名次≤N的行数少于N；DENSE_RANK()不跳号（如1、2、2、3），确保档位连续、不缺档。
RANK() 和 DENSE_RANK() 不是“怎么用对”的问题，而是“选哪个才不翻车”的问题——并列要不要跳号，直接决定你查 Top N 时漏不漏数据、分档时缺不缺档。
查 Top N 时为什么 RANK() 可能返回少于 N 行
因为 RANK() 在并列后会跳过后续名次。比如三人分数为 100、95、95，RANK() 给出的是 1、2、2，下一名次直接是 4；所以 WHERE rnk 实际只命中前两行（<code>1 和两个 2），但 rnk = 3 根本不存在，第三高分被跳过了。
- 用 RANK() 做 “销售额前 3 名” 查询，若第 2 名有 5 人并列，结果会返回 6 行（1 个第 1 名 + 5 个第 2 名），但第 3 名（即第 4 高值）不会出现在结果里
- DENSE_RANK() 在同样数据下给出
1、2、2，WHERE dense_rank 能稳定覆盖前三档值，但可能返回远超 3 行（比如 10 人并列第 2 名） - 真正想取“严格最多 3 条记录”，该用
ROW_NUMBER()；想保全所有并列者且接受断号，才用RANK()
分档场景下 DENSE_RANK() 为什么更稳
当业务要求“必须分 A/B/C 三档”，且每档对应排名 1/2/3 时，DENSE_RANK() 是唯一选择。它保证名次连续、不跳空，哪怕 20 人并列第 2 名，他们的 dense_rank 都是 2，不会出现 3 缺失导致 C 档为空的情况。
- RANK() 在相同输入下可能产出
1、1、3、4，导致档位编号断层，下游系统按rk = 2查 B 档会查不到任何数据 - DENSE_RANK() 的逻辑是“值变才加 1”，所以只要排序字段值相同，名次就复用，天然适配固定档位划分
- 注意：它不合并行，只是给每行打上档位标签；输出仍是原始行数，不是聚合结果
ORDER BY 写错会让并列逻辑彻底失效
并列判定只看 ORDER BY 子句中**最左字段的值是否相等**，后面字段仅用于破 ties（打散顺序），不影响是否并列。错误地把破 ties 字段混进主排序，会导致本该并列的行被强行拆开。
- 错误写法：
RANK() OVER (ORDER BY sales DESC, customer_count ASC)→ 即使sales相同，只要customer_count不同，名次就不同 - 正确写法：
RANK() OVER (ORDER BY sales DESC) AS rk，再在最终ORDER BY里加sales DESC, customer_count ASC控制展示顺序 - 如果主排序字段含 NULL，默认行为因数据库而异（PostgreSQL 默认
NULLS LAST，MySQL 不支持该语法），建议显式用COALESCE(sales, 0)或CASE WHEN sales IS NULL THEN 0 ELSE sales END
WHERE 中直接引用排名别名一定会报错
窗口函数在 SELECT 阶段执行，而 WHERE 在 SELECT 之前运行，此时 rnk 别名根本不存在。所有试图在 WHERE 里写 rnk 的语句都会失败，报错类似 <code>column "rnk" does not exist 或 Invalid use of window function。
- 唯一合法做法是套一层子查询或 CTE：
SELECT * FROM (SELECT *, RANK() OVER (ORDER BY revenue DESC) AS rnk FROM sales) t WHERE rnk - 如果还用了
PARTITION BY dept，却漏写，结果就是全表统一排名，而非“每个部门内排名”——业务语义完全歪掉 - 聚合后排名（如按部门总销售额排名）必须先
GROUP BY出结果，再在外层套窗口函数，不能和聚合混在同一层 SELECT
真正容易被忽略的点是：跳不跳号本身不是技术限制，而是业务契约。一旦选错函数，下游过滤、报表分组、权限控制都可能连锁出错，而且这种错误往往在数据量小的时候看不出来，等上线后并列一多就突然崩。
