MySQL 8.0中ROW_NUMBER()必须配合ORDER BY，否则报错；支持PARTITION BY实现分组内排序取前N名，编号连续不跳号。
MySQL 8.0里用ROW_NUMBER()取前N名必须加ORDER BY
不写ORDER BY直接套ROW_NUMBER() OVER()会报错：Window 'w' requires an ORDER BY clause。这不是可选项，是语法强制要求——哪怕你只想要“任意N条”，也得显式声明排序依据，否则窗口函数无法确定行序。
实操建议：
- 若业务真不关心顺序（比如随机抽样），用
ORDER BY RAND()，但注意性能差，大数据量慎用 - 若按某字段升序取前3名，写
ORDER BY score ASC；降序则用DESC，别漏掉 - 复合排序更常见，比如
ORDER BY status DESC, created_at DESC，确保逻辑可复现
为什么ROW_NUMBER()比LIMIT更适合“分组内前N名”
LIMIT只能做全局截断，而真实场景常要“每个部门薪资最高的2人”这类需求——ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY salary DESC)才能实现。
关键差异：
-
PARTITION BY划分逻辑组，每组独立编号；LIMIT做不到分组粒度 - 编号从1开始连续，不会跳过重复值（这点和
RANK()不同） - 若同一组内有并列高分，
ROW_NUMBER()仍强制给不同序号，比如两人同为100分，会标为1和2
示例：查每个category销量前2的商品
SELECT * FROM (
SELECT *,
ROW_NUMBER() OVER (
PARTITION BY category
ORDER BY sales DESC
) AS rn
FROM products
) t WHERE rn <= 2;
ROW_NUMBER()的性能陷阱：临时表和排序开销
窗口函数执行时，MySQL需先完成PARTITION BY分组和ORDER BY排序，再编号——这意味着全量数据可能被拉入临时表，尤其当分区键无索引或排序字段未建索引时，EXPLAIN会显示Using filesort和Using temporary。
优化要点：
- 确保
PARTITION BY字段和ORDER BY字段联合建索引，例如(category, sales) - 避免在
ROW_NUMBER()子查询里嵌套复杂计算，先过滤再编号（WHERE写在子查询外层不如内层高效） - 如果只取前N且N很小，考虑用
GROUP_CONCAT() + SUBSTRING_INDEX()等老办法对比性能，某些场景反而更快
和RANK()、DENSE_RANK()混用时的序号行为差异
三者都生成序号，但处理并列的方式完全不同，选错会导致“前N名”漏掉本该入选的记录。
假设分数为[100, 100, 95, 90]：
-
ROW_NUMBER()→[1, 2, 3, 4]（严格递增，无并列） -
RANK()→[1, 1, 3, 4]（并列占位，跳过后续序号） -
DENSE_RANK()→[1, 1, 2, 3]（并列不占位，连续编号）
所以“取总分前3名”时：RANK()可能返回4条记录（两个第1名+一个第3名），而ROW_NUMBER()一定只有3条。业务语义决定函数选择，不能默认套用。
真正难处理的是“并列也算前N，但总数不能超N”这种模糊需求——这时得结合ROW_NUMBER()和RANK()双计算，或改用业务层去重。
