RANK()跳号是因其语义为“并列同名次且后续名次跳过被占位数”，如分数100、95、95、88对应排名1、2、2、4；需改用DENSE_RANK()消除跳号，且必须通过子查询或CTE在WHERE中过滤。
RANK() 会跳号，DENSE_RANK() 不跳——这不是风格差异，是业务语义是否允许“空档”的硬性选择。
为什么 RANK() 的结果里突然少了第 2 名
根本原因是：并列导致名次跳过。比如分数为 100、95、95、88 的四人，RANK() OVER (ORDER BY score DESC) 给出的是 1、2、2、4——第 3 名被跳掉了。
- 常见错误现象：
WHERE rank 过滤时漏掉 <code>score = 88那行，因为它的rank是4，但直觉上它确实是“第四高分”，理应进 Top 4 - 这不是 bug，是设计行为：RANK 强调“段位断层”，两个第二名之后，第三档直接叫“第四名”
- 如果业务要的是“取分数最高的前 N 档人”，而不是“取排名值 ≤ N 的人”，那就不能依赖 RANK 的数值做 WHERE 过滤
DENSE_RANK() 怎么保证名次连续不跳
DENSE_RANK() 在遇到相同排序值时，只推进一次名次计数。上例中它给出 1、2、2、3，后续所有名次都紧贴前一个。
- 适用场景明确：按销售额分 A/B/C 三档，必须有且仅有三档，不能缺档也不能多档
- 注意陷阱：它不会合并行，只是编号连续；
score = 95的两人仍各自占一行，dense_rank值都是2 - 如果用它做 Top N 查询（如
WHERE dense_rank ），返回的行数可能远超 N（比如 10 人并列第 2 名，就会返回 11 行）
在视图或子查询里用错 PARTITION BY 会彻底歪掉语义
想算“每科成绩的班级内排名”，却只写 RANK() OVER (ORDER BY score DESC)，结果是全校统一排——不是错，是逻辑全错。
- 必须显式加上
PARTITION BY subject，否则窗口范围默认是整个结果集 -
PARTITION BY字段必须出现在视图的SELECT列表中，否则外部查询无法对齐分组（例如视图没选subject，却在OVER里分区，多数数据库会报错或静默忽略） - 性能提示：在
(subject, score)上建复合索引，能显著减少大表排序开销
MySQL 5.7 及更早版本根本不认识 RANK 和 DENSE_RANK
在旧版 MySQL 上执行含 OVER 的语句，会直接报错：ERROR 1064 (42000): You have an error in your SQL syntax。
- MySQL 8.0+、PostgreSQL、SQL Server、Oracle 支持；SQLite 和 MySQL 5.7 不支持窗口函数
- 别指望“加个括号就能跑”，这是语法层级的不兼容，不是配置问题
- 若必须兼容旧版，只能用变量模拟（如
@rank := IF(@prev = score, @rank, @rank + 1)），但需严格初始化 + 强制ORDER BY，否则结果不可靠
真正容易被忽略的点是：RANK() 和 DENSE_RANK() 的输出值本身不能用于 WHERE 或 HAVING——因为窗口函数在逻辑执行顺序中晚于 WHERE，必须包一层子查询或 CTE 才能过滤排名结果。
