<p>正确写法是：外层查询需用WHERE子句筛选rn <= N，且ROW_NUMBER()必须在子查询或CTE中生成。例如：WITH t AS (SELECT , ROW_NUMBER() OVER (PARTITION BY group_col ORDER BY score DESC) AS rn FROM table) SELECT FROM t WHERE rn <= N。</p>
ROW_NUMBER() 怎么写才能正确取每组前 N 条？
直接用 ROW_NUMBER() OVER (PARTITION BY group_col ORDER BY score DESC) 生成序号，再在外层筛选 rn —— 这是最可靠的方式。不能在 <code>WHERE 中直接写窗口函数，会报错 WINDOW FUNCTION IS NOT ALLOWED HERE，必须用子查询或 CTE 包一层。
常见错误是把 ORDER BY 写成升序、漏写 PARTITION BY（结果变成全表排序）、或在 GROUP BY 后误加窗口函数（语法不通过）。
-
PARTITION BY必须明确指定分组字段，比如按部门PARTITION BY dept_id -
ORDER BY建议用确定性排序，如果分数相同，加个二级排序如ORDER BY score DESC, id ASC避免每次执行结果不一致 - MySQL 8.0+、PostgreSQL、SQL Server、Oracle 都支持；SQLite 3.25+ 也支持，但旧版不支持
和 RANK()、DENSE_RANK() 混用会出什么问题？
要严格“前 N 名且不并列”，只能用 ROW_NUMBER()。如果用 RANK()，相同分数会共享名次（比如两个 95 分都是第 1 名），第 3 名就跳成第 3 名，导致实际返回超过 N 行；DENSE_RANK() 虽然不跳名次，但依然并列，同样无法保证“恰好 N 条”。
举个例子：某组有 5 条数据，分数为 [100, 95, 95, 90, 85]，取前 2 名：
-
ROW_NUMBER()→ 返回 2 条（100 和第一个 95） -
RANK()→ 返回 3 条（100、两个 95 都算第 1 名，rank 就包含全部三个） -
DENSE_RANK()→ 同样返回 3 条（100=1，95=2，90=3，所以rank 仍含前三）
性能差、查不动？几个关键优化点
窗口函数本身不走索引，ORDER BY 字段没索引时，大数据量下容易慢。不是加了 ROW_NUMBER() 就自动优化。
- 确保
PARTITION BY+ORDER BY字段上有联合索引，例如(dept_id, score DESC) - 避免在子查询里做复杂 JOIN 或计算后再开窗，尽量把过滤（
WHERE）提前到子查询外层之前 - PostgreSQL 中可考虑用
LATERAL JOIN替代全量开窗（尤其 N 很小、分组很多时），MySQL 则没有原生替代方案 - 如果只是取 Top 1，部分场景用
GROUP BY + MAX()或关联子查询反而更快，别无脑套窗口函数
MySQL 5.7 或更老版本怎么办？
不支持窗口函数，得绕路。最常用的是自增变量法，但要注意执行顺序不可靠，尤其在有 ORDER BY 或并发环境下容易错序。
示例（仅限单线程、无并发、已按分组和排序字段预排序的场景）：
SELECT dept_id, name, score FROM (
SELECT dept_id, name, score,
@rn := IF(@prev = dept_id, @rn + 1, 1) AS rn,
@prev := dept_id
FROM scores, (SELECT @rn := 0, @prev := '') AS _
ORDER BY dept_id, score DESC
) t WHERE rn <= 3;
这个写法在 MySQL 8.0+ 已被标记为“不推荐”，且无法保证稳定；生产环境建议升级或改用应用层分组处理。真正需要兼容老版本时，优先评估是否能接受用临时表 + 循环查询代替。
注意：变量赋值顺序依赖 ORDER BY 执行时机，而 MySQL 不保证变量在 SELECT 中的求值顺序，所以这个方案本质上是脆弱的。
