MySQL 8.0强制ROW_NUMBER()的OVER子句必须含ORDER BY，否则报错；PARTITION BY缺失会导致全表排序而非分组排序；正确用法需同时指定PARTITION BY和ORDER BY，并推荐用CTE封装后再过滤。
ROW_NUMBER() 必须带 ORDER BY，否则直接报错
MySQL 8.0 强制要求 ROW_NUMBER() 的 OVER() 子句里必须包含 ORDER BY，漏写会立刻报 ERROR 3593: Window function 'row_number' requires an OVER clause with ORDER BY。这不是可选项，是语法硬性限制。
- 常见错误写法：
ROW_NUMBER() OVER (PARTITION BY dept_id)—— 缺少ORDER BY，一定失败 - 正确写法（按薪资降序）：
ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY salary DESC) - 如果真不关心业务排序，可用主键兜底：
ORDER BY id或ORDER BY created_at，但别用ORDER BY 1，结果不可靠
PARTITION BY 漏写 = 全表误排，不是不准而是逻辑错
想查“每个部门工资前三”，却只写 ROW_NUMBER() OVER (ORDER BY salary DESC)，结果是全校统一编号，不是每部门独立编号——这已经不是性能或精度问题，是语义完全偏离需求。
-
PARTITION BY定义“谁跟谁比”，不写就默认全表为一个分区 - 典型翻车场景：在子查询里加了
PARTITION BY，但外层WHERE过滤后破坏了分组完整性，导致rn = 1不再代表组内首行 - 安全做法：用 CTE 或派生表封装窗口计算，再在外层过滤，例如：
SELECT * FROM (SELECT *, ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY salary DESC) AS rn FROM emp) t WHERE rn
ROW_NUMBER() vs RANK() vs DENSE_RANK()：并列时行为完全不同
“前三名”在业务中通常指物理上前三条记录，而不是“排名 ≤ 3”的人。选错函数会导致名单多出或遗漏——比如成绩 [95,95,90,90,85] 时：
-
ROW_NUMBER()给出1,2,3,4,5—— 严格连续，适合取固定条数（如每组前3条） -
RANK()给出1,1,3,3,5—— 并列跳号，WHERE rank 会漏掉第4名实际是第3个分数段 -
DENSE_RANK()给出1,1,2,2,3—— 并列不跳，但“第3名”只对应一个分数，不适合“取前3条记录”场景
ORDER BY 字段没索引，窗口函数会变慢且结果可能非确定
ROW_NUMBER() 执行时需完成分组和排序，若 ORDER BY 字段无索引，EXPLAIN 常见 Using filesort 和 Using temporary，大数据量下延迟明显；更隐蔽的风险是：当排序字段有重复值且无二级排序时，MySQL 可能返回不同行序。
- 建议对
ORDER BY字段建联合索引，例如：(category, sales DESC)加速ROW_NUMBER() OVER (PARTITION BY category ORDER BY sales DESC) - 避免仅靠
sales DESC排序，补上唯一字段保证稳定性：ORDER BY sales DESC, id ASC - 不要依赖
ORDER BY RAND()做随机 Top-N，大数据量时性能极差
真正容易被忽略的，是 ORDER BY 字段重复 + 无二级排序带来的非确定性——同一 SQL 在不同时间、不同并发压力下可能返回不同行，而你根本不会报错。
