row_number() 必须搭配明确的order by子句，否则报错；它严格递增且唯一，即使排序列有重复值；外层order by不影响其计算；非索引字段排序会导致性能骤降。
ROW_NUMBER() 必须搭配 ORDER BY 才能生效
不写 ORDER BY 的 ROW_NUMBER() 是非法的——SQL 标准强制要求窗口函数必须有明确排序依据。哪怕你只想“按原样编号”，也得显式指定一个确定性排序字段，否则会直接报错：Window function requires an ORDER BY clause（PostgreSQL/SQL Server）或类似提示。
常见误区是以为加了 ORDER BY (SELECT NULL) 或 ORDER BY 1 就能“保持输入顺序”，但这是不可靠的：优化器可能重排、并行执行可能打乱、不同版本行为也不一致。
- ✅ 正确做法：用一个**唯一且稳定**的列排序，比如主键
id、时间戳created_at，或组合键（如(user_id, event_time)） - ⚠️ 避免用
ORDER BY RAND()或无索引字段——会导致全表扫描+排序开销飙升 - ? 如果原始数据真没天然顺序，可先用
CTE+ROW_NUMBER() OVER (ORDER BY id)生成临时序号，再基于它做后续操作
多行同值时 ROW_NUMBER() 仍保证唯一编号
ROW_NUMBER() 的核心特性是“严格递增、绝不重复”，哪怕 ORDER BY 列存在重复值（比如多个用户注册时间相同），它也会按内部处理顺序补位，结果仍是 1,2,3… 而不是像 RANK() 那样跳号。
这意味着：如果你依赖编号做分页或取第 N 条，ROW_NUMBER() 更可控；但若想按业务逻辑“并列排名”，就得换用 RANK() 或 DENSE_RANK()。
- ✅ 场景适用：分页（
WHERE rn BETWEEN 11 AND 20）、去重取最新一条（WHERE rn = 1） - ⚠️ 注意：同值行的相对编号顺序不保证跨执行一致——除非
ORDER BY子句本身已完全确定（例如加二级排序：ORDER BY status, id） - ? 补救方案：在
ORDER BY中追加主键，如ORDER BY created_at DESC, id DESC，彻底消除歧义
嵌套查询中 ORDER BY 不能替代窗口函数的 ORDER BY
外层查询的 ORDER BY 不会影响 ROW_NUMBER() 的计算顺序——窗口函数的排序是在其所在子查询/CTE 内独立完成的。很多人误以为“最后排个序就行”，结果发现编号和最终显示顺序对不上。
典型错误写法：
SELECT *, ROW_NUMBER() OVER () AS rn FROM users ORDER BY name;
这会报错（缺 ORDER BY），而改成：
SELECT *, ROW_NUMBER() OVER (ORDER BY name) AS rn FROM users ORDER BY name;
看似合理，但 rn 是按 name 排序生成的，如果 name 有重复，rn 的分配顺序仍不确定，且外层 ORDER BY 只影响最终输出，不改变 rn 值本身。
- ✅ 正确结构：用 CTE 或子查询封装，确保窗口排序与业务意图一致
- ⚠️ 禁止省略窗口内的
ORDER BY，哪怕只是为凑合语法而加ORDER BY id - ? 复杂排序逻辑建议提取到 CTE，避免在
OVER()里写过长表达式影响可读性
性能敏感场景下慎用非索引字段排序
ROW_NUMBER() 的 ORDER BY 字段如果没有对应索引，数据库大概率要走文件排序（Using filesort），尤其在大数据量时延迟陡增。这不是函数本身慢，而是排序成本高。
比如对千万级订单表按 customer_name 编号，而该字段无索引，执行计划里常看到 Sort 节点占耗时 70% 以上。
- ✅ 提前检查执行计划：PostgreSQL 用
EXPLAIN ANALYZE，MySQL 看Extra是否含Using temporary; Using filesort - ⚠️ 避免在
ORDER BY中用函数包裹字段（如ORDER BY UPPER(name)），会失效索引 - ? 索引设计建议：对高频用于
ROW_NUMBER()排序的字段建联合索引，例如(status, created_at, id)匹配ORDER BY status, created_at DESC, id
稳定顺序不是靠“加个函数”就能实现的，它本质是排序策略 + 索引支撑 + 明确业务语义的组合结果。漏掉其中任何一环，编号就可能在某次查询里突然错乱。
