多级分组排名应选rank()或dense_rank()而非row_number()：rank()跳过重复名次，dense_rank()连续编号；必须配合PARTITION BY和ORDER BY，且WHERE筛选需用子查询避免破坏分组。
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 的前缀。
- 单列索引对多级分组效果有限，联合索引才有效
- PostgreSQL 中，
ORDER BY revenue DESC NULLS LAST要求索引也声明DESC NULLS LAST才能命中 - 如果只是取每组 TOP N，考虑用
LATERAL JOIN或FETCH FIRST N ROWS ONLY配合索引，有时比全量排名更快
user_id 和 date 分组，但数据存在毫秒级时间戳，date 截断后导致本该分开的组被合并。这种细节不会报错，但统计口径就偏了。 
