rank() 与 dense_rank() 的根本区别在于并列时是否跳过后续名次：rank() 跳过，dense_rank() 连续；二者均为窗口函数，须带 order by，不支持 rows between，不可与 group by 混用，正确用法是配合 partition by 实现分组内排名。
为什么 RANK() 和 DENSE_RANK() 排名结果不一样
根本区别在「相同值是否占用后续排名位置」：遇到并列时，RANK() 跳过后续名次，DENSE_RANK() 则连续排。比如三行值都是 100，RANK() 给出 1, 1, 1, 4...，DENSE_RANK() 是 1, 1, 1, 2...。
常见错误现象：RANK() 返回的数字突然“跳一大截”，误以为数据漏了或窗口写错了；其实只是并列导致的正常行为。
- 使用场景：按销售额分组内排名时，若需「第1名、第2名、第3名…」这种直观序号，选
DENSE_RANK()；若要体现「并列第1名之后确实是第4名」的严格位次（如奥运奖牌榜），用RANK() -
ORDER BY子句必须存在，否则报错window function requires an ORDER BY clause - 两者都不支持
ROWS BETWEEN等帧定义——它们天然作用于整个分区，不能限制“只看前3行”
GROUP BY 后不能直接用 RANK()？得用窗口函数写法
很多人写 SELECT dept, RANK() OVER (ORDER BY salary) FROM emp GROUP BY dept，结果报错或逻辑错。因为 RANK() 是窗口函数，不是聚合函数，不能和 GROUP BY 混用，也不能省略 PARTITION BY 来模拟“分组内”效果。
正确做法是用 PARTITION BY 明确划分组，再在组内排序：
SELECT dept, name, salary, RANK() OVER (PARTITION BY dept ORDER BY salary DESC) AS rnk FROM emp;
- 漏写
PARTITION BY dept→ 全表统一排名，不是“组内” - 把
ORDER BY写成升序却想要“最高薪排第1”，忘了加DESC - MySQL 8.0+、PostgreSQL、SQL Server、Oracle 都支持；但 SQLite 默认不支持窗口函数（需编译启用）
性能差？别在大表上无过滤用 RANK() OVER (PARTITION BY ...)
窗口函数需要对每个分区做内部排序，PARTITION BY 值越分散、分区越多，临时排序开销越大。100 万行员工表按部门分组排名，如果部门有 5000 个，就等于做 5000 次小排序——比全表一次排序还慢。
- 优化方向：先
WHERE dept IN ('tech', 'sales')缩小数据集，再开窗 - 索引建议：在
(dept, salary)上建联合索引，能加速PARTITION BY dept ORDER BY salary的执行 - 替代思路：如果只要 Top 3，用
ROW_NUMBER() OVER (...) 过滤后，比全量排名再 <code>WHERE rnk 更快
NULL 值怎么排？ORDER BY 默认把 NULL 放最后，但可改
当 salary 有 NULL，ORDER BY salary DESC 默认把 NULL 当作最小值，排在最末——所以 RANK() 会把 NULL 行标为最大名次（比如第100名）。这未必符合业务预期。
- 想让
NULL排最前：写成ORDER BY salary DESC NULLS FIRST（PostgreSQL、Oracle、SQL Server 2022+ 支持） - MySQL 和旧版 SQL Server 不支持
NULLS FIRST/LAST，得用ORDER BY IFNULL(salary, 9999999) DESC临时填充 - 注意：不同数据库对
NULL的默认排序方向可能不同（如 PostgreSQL 默认NULLS LAST，MySQL 取决于 SQL mode）
真正麻烦的是跨数据库移植——同一段含 NULLS FIRST 的 SQL，在 MySQL 里直接报错，得提前判断方言再调整写法。
