RANK()遇相同值跳过后续名次，DENSE_RANK()不跳；如分数95,95,90，前者得1,1,3，后者得1,1,2；二者均需显式ORDER BY，不支持ROWS BETWEEN，且NULL处理需谨慎。
MySQL 8.0 中 RANK() 和 DENSE_RANK() 的行为差异
RANK() 和 DENSE_RANK() 都会按 ORDER BY 排序后分配整数排名，但遇到相同值时处理“跳名”逻辑不同：RANK() 跳过后续名次，DENSE_RANK() 不跳。比如三个人分数为 95, 95, 90，RANK() 给出 1, 1, 3，DENSE_RANK() 给出 1, 1, 2。这个差异直接影响报表中“第几名”的语义是否连续。
实际使用时，别只看文档描述——必须在真实数据上验证。常见误判是把 DENSE_RANK() 当成“不重复排名”，其实它只是不跳名，重复值仍共享同一排名。
- RANK() 等价于“并列后空一格”，适合强调名次层级（如奥运奖牌榜）
- DENSE_RANK() 等价于“并列后紧接下一个数字”，适合做分档位（如 Top 3、Top 5 连续区间）
- 两者都不支持
ROWS BETWEEN窗口帧子句，仅依赖ORDER BY定义逻辑顺序
写法要点：PARTITION BY + ORDER BY 缺一不可
窗口函数必须显式声明排序依据，否则报错 Window 'w' lacks an ORDER BY clause。即使你只想按自然插入顺序排，也得用一个确定性字段（如主键 id 或时间戳 created_at）代替 ORDER BY NULL（MySQL 8.0 不允许）。
分区（PARTITION BY）不是必须的，但漏掉会导致全表统一排名，而非分组内排名。例如统计每个部门员工薪资排名，必须写 PARTITION BY dept_id，否则所有员工混在一起排。
- 错误写法：
SELECT name, salary, RANK() OVER () AS rk FROM emp;→ 报错 - 正确写法：
SELECT name, salary, RANK() OVER (PARTITION BY dept_id ORDER BY salary DESC) AS rk FROM emp; - 若不分组，仍需写
ORDER BY：RANK() OVER (ORDER BY score DESC)
和 ROW_NUMBER() 混用时的陷阱
三者常被一起选出来对比：ROW_NUMBER() 总是生成唯一递增序号，不管值是否重复；RANK() 和 DENSE_RANK() 则对相同值赋予相同排名。但很多人忽略一点：当 ORDER BY 字段存在 NULL 时，MySQL 默认把 NULL 当作最小值（NULLS FIRST），而多数业务希望 NULL 排最后或单独过滤。
如果不处理，可能导致 RANK() 把一堆 NULL 全标为 1，掩盖真实数据分布。
- 显式控制 NULL 位置：
ORDER BY score DESC NULLS LAST（MySQL 8.0.22+ 支持） - 低版本兼容写法：
ORDER BY IF(score IS NULL, 1, 0), score DESC - 更稳妥的做法：提前
WHERE score IS NOT NULL，避免排名逻辑被脏数据干扰
性能与索引建议
窗口函数本身不走索引，但 ORDER BY 字段如果有对应索引，能显著加快排序阶段。尤其在大表上，没索引时可能触发磁盘临时表，导致慢查询。
注意：复合索引要匹配 PARTITION BY + ORDER BY 顺序。例如用 PARTITION BY dept_id ORDER BY salary DESC，推荐建索引 INDEX(dept_id, salary)（B+Tree 天然支持前缀匹配和范围扫描）。
- 单字段排序（无 PARTITION BY）：索引
INDEX(score)即可 - 有 PARTITION BY 且高频查询：优先建联合索引，而非两个单列索引
- 避免在 ORDER BY 中用函数，如
ORDER BY ABS(score)，会导致索引失效
复杂排名逻辑（比如多层嵌套窗口、配合聚合）容易让执行计划变重，上线前务必用 EXPLAIN ANALYZE 看实际耗时，而不是只信 SELECT 结果正确。
