ROW_NUMBER() 必须与 PARTITION BY 和 ORDER BY 联用，否则报错或结果不可控；它在每个分区内独立排序编号，要求分区字段为实际列、排序字段重复时仍生成唯一序号，且需嵌套子查询才能过滤序号。
ROW_NUMBER() 必须配合 PARTITION BY 和 ORDER BY 使用
单独写 ROW_NUMBER() 不会返回有意义的序号，它必须和 PARTITION BY（分组）与 ORDER BY（排序）一起出现，否则会报错或结果不可控。比如想按部门取薪资前3的员工，PARTITION BY dept_id 划分组，ORDER BY salary DESC 决定谁排第1、第2……
常见错误是漏掉 ORDER BY，这时数据库可能允许执行但返回随机序号；或者把 ORDER BY 写在外部查询里，那 ROW_NUMBER() 已经算完了，再排没用。
-
ROW_NUMBER()的排序是在每个分区内独立进行的，不是全表排序后编号 - 分区字段必须是实际存在的列，不能是表达式（如
PARTITION BY UPPER(name)在部分数据库不支持） - 如果
ORDER BY字段有重复值，ROW_NUMBER()仍会强制给出唯一递增序号（不像RANK()那样并列）
嵌套子查询是实现“分组 Top N”的标准写法
不能直接在 WHERE 中过滤 ROW_NUMBER()，因为窗口函数不能出现在 WHERE 或 GROUP BY 中。必须先用子查询或 CTE 把序号算出来，再在外层筛选 rn 。
例如取每个部门工资最高的3人：
SELECT dept_id, name, salary
FROM (
SELECT dept_id, name, salary,
ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY salary DESC) AS rn
FROM employees
) t
WHERE t.rn <= 3;
- 别名
t必须加，否则外部查询无法引用rn - 某些数据库（如 MySQL 8.0+、PostgreSQL、SQL Server）支持 CTE，可读性更好，但底层逻辑一样
- Oracle 中若用旧版（11g 及以前），需用
ROWNUM模拟，但无法直接分组，必须结合子查询嵌套
性能陷阱：ORDER BY 字段没索引会导致全表扫描
ROW_NUMBER() 的 ORDER BY 部分如果没有对应索引，数据库大概率要对每个分组做排序操作，数据量一大就慢。尤其当分组内记录多、分组数也多时，开销呈倍数增长。
- 理想索引是复合索引：
(dept_id, salary DESC)—— 先按分区字段等值查找，再按排序字段范围扫描 - 如果
ORDER BY用的是表达式（如ORDER BY ABS(salary)），多数数据库无法走索引，得考虑物化或预计算 - MySQL 5.7 对窗口函数优化较弱，同样逻辑在 8.0+ 里快很多；PostgreSQL 一般处理得更稳
注意 NULL 值和排序方向对 Top N 结果的影响
NULL 在 ORDER BY ... DESC 中通常排最后，所以如果最高薪字段有 NULL，它们不会被误选进 Top N；但若用 ASC 取最小值，NULL 可能意外排第一（取决于 SQL 方言和 NULLS FIRST/LAST 设置）。
- PostgreSQL 支持
NULLS LAST显式控制，MySQL 和 SQL Server 默认行为不同，需实测 - 如果业务要求 “相同分数并列算一个名额”，该用
RANK()或DENSE_RANK()，而不是ROW_NUMBER() - 当
ORDER BY字段类型是字符串且含大小写混合时，注意排序规则（collation），否则 'Z' 可能排在 'a' 前面
真正卡住人的往往不是语法写不对，而是分区键选错、排序字段没索引、或者忘了 NULL 在不同数据库里的默认排序位置。
