GROUP BY + LIMIT 无法实现每组取前N条，因LIMIT作用于最终结果而非分组内；ROW_NUMBER()配合PARTITION BY可精确编号组内行，需子查询过滤rn≤N。
为什么直接用 GROUP BY + LIMIT 不行
因为 GROUP BY 会压缩行，而 LIMIT 是在最终结果集上生效的——它压根不知道“每个组里取前 N 条”这件事。你写 SELECT * FROM t GROUP BY category ORDER BY score DESC LIMIT 3，得到的是全局前 3 行，不是每个 category 的 Top 3。
ROW_NUMBER() 是最稳妥的组内排序方案
它为每组内的行严格编号（1, 2, 3…），不会跳号，适合“取第 1 名”或“取前 N 名”这种精确位置需求。
实操要点：
- 必须配合
PARTITION BY指定分组字段，比如PARTITION BY category -
ORDER BY写在OVER里，决定组内排序逻辑，例如ORDER BY score DESC, id ASC（分数相同按 id 升序保确定性） - 别在外部 WHERE 中直接过滤
ROW_NUMBER() > 1—— 窗口函数不能在 WHERE 或 GROUP BY 中引用，得套一层子查询或 CTE - 示例：查每个
category下 score 最高的 3 条记录
RANK()
- 要严格限制返回条数 → 用
ROW_NUMBER() - 要体现真实名次（允许并列）且接受可能超量 → 用
RANK()或DENSE_RANK() - MySQL 8.0+、PostgreSQL、SQL Server、Oracle 都支持；SQLite 3.25+ 支持，旧版不支持窗口函数
性能和索引建议
窗口函数本身不走索引，但 PARTITION BY + ORDER BY 字段组合如果存在联合索引，能显著加速排序阶段。
例如对 PARTITION BY category ORDER BY score DESC，建索引：CREATE INDEX idx_cat_score ON products(category, score DESC);
还要注意：
- 大数据量下，
ROW_NUMBER()必须扫描并排序整个分区，内存/磁盘临时表开销不可忽视 - 避免在窗口函数中调用复杂表达式或子查询，会拖慢每一行的计算
- 如果只是查 Top 1，部分数据库（如 PostgreSQL）用
DISTINCT ON可能更快，但跨数据库可移植性差
真正麻烦的不是语法，是想清楚你要的是“第 N 个位置”还是“分数不低于第 N 名的全部人”——这个语义差别，直接决定该用哪个函数。
