如何用SQL实现多级分组的排名统计_窗口函数扩展-SQL-PHP中文网

多级分组排名应选rank()或dense_rank()而非row_number()：rank()跳过重复名次，dense_rank()连续编号；必须配合PARTITION BY和ORDER BY，且WHERE筛选需用子查询避免破坏分组。

如何用sql实现多级分组的排名统计_窗口函数扩展

rank() 和 dense_rank() 在多级分组中行为差异明显

多级分组排名的核心不是“怎么写”，而是“选哪个函数”——rank() 会跳过重复名次后的编号，dense_rank() 则连续编号。比如同一组内三个并列第1，rank() 下一个是第4，dense_rank() 下一个是第2。

实际场景中，业务方说“并列后下一个名次是多少”，得先确认是按跳号（如体育比赛奖牌榜）还是按顺位（如考试成绩单）。别默认用 row_number()，它不处理并列，纯按顺序硬排，容易引发数据质疑。

rank()：适合强调“名次层级”，比如销售榜单里并列冠军后直接是第四名
dense_rank()：适合强调“位置序号”，比如按城市+月份统计销量TOP3，要确保每组最多取3行
所有函数都必须配合 PARTITION BY 指定多级分组字段，例如 PARTITION BY region, product_category

PARTITION BY 多字段顺序影响结果可读性

写 PARTITION BY dept, team, year 和 PARTITION BY year, dept, team 逻辑等价，但输出排序和调试时的直观性差很多。数据库不会报错，但人容易看串——尤其当结果集没显式 ORDER BY 时，分组内行序是不确定的。

建议把高基数、低变动频率的字段放前面，比如时间维度（year、quarter）通常比组织维度（team）更稳定，也更符合分析习惯。否则可能发现“2023年A组第1名”排在“2022年A组第1名”下面，但中间夹着一堆2023年B组数据，查起来费劲。

分组字段顺序不影响计算正确性，但影响结果集天然聚类程度
务必搭配 ORDER BY 子句在窗口内明确排序依据，例如 ORDER BY revenue DESC, employee_id
如果分组字段含 NULL，不同数据库处理方式不同：PostgreSQL 默认把 NULL 排最前，MySQL 8.0+ 可用 NULLS LAST 控制，SQL Server 不支持该语法

WHERE 和窗口函数不能直接互换位置

常见错误是想“先筛选再排名”，却把条件写在 WHERE 里，导致分组被破坏。例如：只统计“销售额 > 10000”的员工排名，但 WHERE sales > 10000 会先过滤掉其他人，使得每个分组只剩达标者——这时的“第1名”其实是该组达标者里的第1，而非全组第1。

真正需求往往是“所有人参与排名，但只显示达标者”。此时必须用子查询或 CTE：外层 WHERE 筛，内层窗口算全量排名。

SELECT dept, name, sales, rk
FROM (
  SELECT dept, name, sales,
         dense_rank() OVER (PARTITION BY dept ORDER BY sales DESC) AS rk
  FROM employees
) t
WHERE sales > 10000;

窗口函数在逻辑执行顺序中晚于 FROM 和 WHERE，早于 ORDER BY 和 LIMIT
不能在 GROUP BY 后直接用窗口函数，除非嵌套一层（因为聚合后行数已变）
某些旧版 MySQL（ORDER BY 稳定性，风险高

性能敏感点：ORDER BY 字段未建索引时开销陡增

多级分组 + 排名 + 大表 = ORDER BY 成瓶颈。窗口函数内部要对每个分组做局部排序，若 PARTITION BY a, b ORDER BY c 中字段 c 没索引，数据库大概率触发磁盘排序，百万级表可能从毫秒级升到秒级。

不是所有组合都需要索引，优先覆盖高频分组+排序组合。例如常按 (region, year) PARTITION BY 并按 revenue DESC 排名，那就建联合索引 INDEX(region, year, revenue)。注意字段顺序：前导字段必须匹配 PARTITION BY 的前缀。