GROUP BY无法获取每组前三名，因其是聚合操作，会压缩行而非保留原行排序筛选；RANK()并列跳号，ROW_NUMBER()严格不并列，存在相同排序值时应选ROW_NUMBER()。
为什么直接用 GROUP BY 拿不到每组前三名
因为 GROUP BY 本身是聚合操作，它把多行压成一行，而“每组前三名”需要保留原始行、按组内排序后筛选——这本质上不是聚合，而是分组排序 + 行过滤。硬套 GROUP BY 加 LIMIT 会报错或只返回全局前三，不是每组的前三。
RANK() 和 ROW_NUMBER() 选哪个更稳妥
RANK() 会并列（比如两个第1名后直接跳到第3名），ROW_NUMBER() 强制不并列（两个第1名会变成第1、第2名）。业务上要“严格取前3条记录”，尤其存在相同排序值时（如分数、时间相同），推荐用 ROW_NUMBER()；若明确接受并列且后续逻辑能处理重复排名（如展示榜单），才用 RANK()。
- 错误写法：
WHERE RANK() OVER (...) —— 窗口函数不能直接出现在 WHERE 中 - 正确结构：必须用子查询或 CTE 把带排名的临时结果先算出来，再外层过滤
- 注意 ORDER BY 子句顺序：窗口函数里的
ORDER BY决定排名依据，和外部排序无关
嵌套查询写法示例（兼容 MySQL 8.0+、PostgreSQL、SQL Server）
以学生表 students（字段：class_id, score, name）为例，查每班分数前三的学生：
SELECT class_id, name, score
FROM (
SELECT class_id, name, score,
ROW_NUMBER() OVER (PARTITION BY class_id ORDER BY score DESC) AS rn
FROM students
) ranked
WHERE rn <= 3;
关键点：
-
PARTITION BY class_id定义分组维度，不是GROUP BY - 如果需并列且允许同分同名都进前三，把
ROW_NUMBER()换成RANK()，但要注意可能返回超过3行 - MySQL 5.7 或更早版本不支持窗口函数，此时只能用自关联或变量模拟，性能差、逻辑易错
性能和索引建议
窗口函数本身不走索引，但 PARTITION BY + ORDER BY 组合列如果有联合索引，能显著加速排序阶段。
- 推荐建索引：
CREATE INDEX idx_class_score ON students(class_id, score DESC); - 大数据量时避免在子查询里 SELECT *，只取必要字段，减少内存开销
- PostgreSQL 中
rank() OVER(...)在ORDER BY含 NULL 时默认把 NULL 排最前，可用NULLS LAST显式控制
真正容易被忽略的是：窗口函数的执行时机晚于 WHERE 但早于 ORDER BY，所以排名计算基于过滤后的数据——如果漏了外层 WHERE 的条件，排名结果就全偏了。
