row_number() 是窗口函数，必须配合 over() 使用，否则报错；需指定 order by 排序和可选 partition by 分组，排序字段应有索引，null 在分组中被视为同一组。
ROW_NUMBER() 必须配合 OVER() 才能用，否则直接报错
不写 OVER() 是最常见错误，比如写成 SELECT ROW_NUMBER(), name FROM users，MySQL 8.0+ 和 PostgreSQL 会报 Window function 'ROW_NUMBER' requires an OVER clause，SQL Server 同样拒绝执行。它不是普通函数，是窗口函数，必须声明“按什么排序、在哪个范围内编号”。
实操建议：
- 排序字段尽量选有索引的列，否则
ORDER BY在OVER()里会显著拖慢大表查询 - 不要在
OVER()里用表达式或函数做排序键（如ORDER BY UPPER(name)），部分数据库无法走索引 - 如果只是想按插入顺序编号，没有天然序号列，别依赖
ORDER BY id——id不等于插入顺序，尤其用自增 + 删除后重用时
分组内编号：PARTITION BY 是关键，漏掉就变成全表连续编号
想对每个部门分别从 1 开始编号，却只写 ROW_NUMBER() OVER (ORDER BY salary DESC)，结果是全公司所有人按薪资排 1、2、3……而不是“技术部第 1 高薪”“销售部第 1 高薪”。PARTITION BY dept_id 才真正实现“分组截取”的基础。
实操建议：
-
PARTITION BY字段必须出现在SELECT或GROUP BY中（取决于是否聚合），否则某些数据库（如 Presto）会报错 - 多个分区字段用逗号分隔：
PARTITION BY region, team，等价于先按 region 分再按 team 细分 - 分区字段值为
NULL会被视为同一组 —— 如果业务上 NULL 表示“未分配”，而你希望它们各自独立，得提前用COALESCE(dept_id, id)处理
用 ROW_NUMBER() 实现“每组取前 N 条”的安全写法
直接 WHERE ROW_NUMBER() OVER (...) 会报错：窗口函数不能出现在 <code>WHERE 子句。必须套一层子查询或 CTE。
实操建议：
- 推荐用 CTE，语义清晰且多数数据库优化器能识别：
WITH ranked AS ( SELECT *, ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY salary DESC) AS rn FROM employees ) SELECT * FROM ranked WHERE rn
- 避免在子查询里多加无用字段，尤其是大文本或 JSON 列——
ROW_NUMBER()计算本身不耗资源，但传输和存储中间结果会拖慢整体 - 如果 N 很大（比如取前 1000），考虑是否真需要全部拉到应用层；有时用分页游标（
WHERE salary ）更高效
不同数据库对 ORDER BY 的严格性差异容易踩坑
PostgreSQL 要求 OVER() 中必须有 ORDER BY；SQL Server 允许省略，但结果不可预测；MySQL 8.0+ 同样强制要求。更隐蔽的是：有些数据库（如 Hive）在 ORDER BY 字段含重复值时，相同值的行编号可能每次查询都不一样 —— 这会导致分页错乱或导出数据不一致。
实操建议：
- 只要涉及分页、导出、下游依赖序号逻辑，
ORDER BY必须包含唯一键兜底，例如：ORDER BY salary DESC, id ASC - 别用
ORDER BY RAND()配合ROW_NUMBER()做随机抽样，性能极差且不可复现；改用TABLESAMPLE或应用层随机 - Oracle 用户注意：
ROW_NUMBER()和RANK()在并列处理上不同，前者严格递增，后者跳号，选哪个取决于业务是否接受“并列第 1 名之后是第 3 名”
实际用起来，最麻烦的往往不是语法，而是想清楚“分组依据是否真的稳定”“排序键有没有隐含重复”“下游系统是否把 row_number 当作绝对顺序依赖”。这些地方一松动，线上就容易出数据错位。
