rank() 跳号并列后空位，dense_rank() 连续编号不跳号；row_number() 强制唯一序号；分组需 PARTITION BY，NULL 排序需 NULLS LAST，窗口函数不可用于 WHERE。
rank() 和 dense_rank() 差在哪？一查排名就错
多维排序时用 rank() 得到“1,1,3,3,5”这种跳号结果，但业务要的是“1,1,2,2,3”——这不是数据错了，是函数选错了。dense_rank() 才是连续编号的正确选择；rank() 会为并列项腾出后续位置，row_number() 则强行打乱序号（哪怕值相同）。
常见错误现象：ORDER BY score DESC 后发现同一分数被分到不同名次；或导出报表时“第2名”直接消失。
- 按部门分组内排名：必须写
PARTITION BY dept_id，漏掉就变成全表排了 - 排序字段含
NULL：默认排最前，若要排最后得加NULLS LAST（PostgreSQL/Oracle 支持，MySQL 8.0 不支持） - 多个排序条件：写成
ORDER BY salary DESC, hire_date ASC，别用逗号隔开两个ORDER BY
MySQL 8.0 窗口函数报错 “This function is not allowed in this context”
不是语法错，是 MySQL 对窗口函数的使用位置极其敏感：不能出现在 WHERE、GROUP BY 或普通子查询里，只能在 SELECT 列表或 HAVING 中直接调用。
典型翻车场景：想筛出“部门内薪资前3的员工”，写了 WHERE dense_rank() OVER (...) —— 直接报错。
- 正确做法：套一层子查询或 CTE，先算排名，再在外层
WHERE过滤 - CTE 写法更清晰：
WITH ranked AS (SELECT *, dense_rank() OVER (PARTITION BY dept_id ORDER BY salary DESC) rnk FROM emp) - MySQL 8.0 不支持
RANGE BETWEEN，别抄 PostgreSQL 文档里的高级帧定义
多字段组合排序时 order by 的字段顺序影响最终排名
窗口函数的 ORDER BY 不是“先按 A 排、再按 B 排”的简单叠加，而是构建一个复合排序键。A 字段相同时才比较 B，但只要 A 不同，B 完全不参与当前行的名次判定。
比如按 region + sales 排名，华东区销售额 100 万和华南区 99 万，前者一定排前面——区域差异直接覆盖销售额差异。
- 业务要“各区域内销售额排名”，必须
PARTITION BY region，否则跨区比毫无意义 - 如果还要求“同销售额时按入职时间早优先”，就得写
ORDER BY sales DESC, hire_date ASC - 注意 ASC/DESC 混用：一个升序一个降序时，别漏掉显式声明，MySQL 默认全是 ASC
性能崩了？窗口函数没索引可优化
窗口函数本身不走索引，OVER (PARTITION BY x ORDER BY y) 的执行代价≈对每个分区做一次排序。千万级表上跑 dense_rank() 可能卡死，不是写法问题，是数据量压过了内存缓冲区。
最容易被忽略的点：PARTITION BY 字段没索引，会导致每次分组都全表扫描。
- 给
PARTITION BY字段建联合索引，例如(dept_id, salary)能加速PARTITION BY dept_id ORDER BY salary DESC - 避免在大表上用
ORDER BY RAND()配合窗口函数——随机排序无法利用索引，必慢 - PostgreSQL 可用
MATERIALIZED VIEW缓存常用排名结果；MySQL 建议预计算后存到冗余字段，用触发器或应用层维护
真正麻烦的从来不是怎么写对 rank，而是当分区变多、排序字段变复杂、数据量破亿之后，你得清楚哪一步开始拖慢整条 SQL。
