row_number()能替代多层嵌套子查询，因其单次表扫描即可完成分组排序与行编号，避免传统子查询每行触发独立扫描导致的o(n²)复杂度，执行更快、结果更稳。
ROW_NUMBER() 为什么能替代多层嵌套子查询
因为 ROW_NUMBER() 是窗口函数，它在不改变原始行数的前提下直接生成序号，而传统嵌套子查询（比如用 (SELECT COUNT(*) FROM t2 WHERE t2.id 模拟排名）会触发多次扫描、关联或自连接，性能随数据量指数级下降。尤其当你要取“每个分组的最新一条”或“全局前 N 条”，用子查询写三层以上很常见，但其实全可压平到一层 <code>SELECT + ROW_NUMBER()。
按时间取每个用户的最新订单（典型嵌套场景）
常见错误写法是先子查询算每个 user_id 的最大 created_at，再连回主表匹配，或者更糟：用相关子查询对每行都查一遍最大时间。正确做法是用 ROW_NUMBER() 配合 PARTITION BY 和 ORDER BY：
SELECT user_id, order_id, created_at
FROM (
SELECT user_id, order_id, created_at,
ROW_NUMBER() OVER (
PARTITION BY user_id
ORDER BY created_at DESC, order_id DESC
) AS rn
FROM orders
) ranked
WHERE rn = 1;
注意点：
-
PARTITION BY user_id对应原嵌套中“按用户分组”的逻辑 -
ORDER BY created_at DESC, order_id DESC确保时间相同时有确定性排序（避免不同执行结果） - 别漏掉外层
WHERE rn = 1，窗口函数不能直接在WHERE中过滤 - MySQL 8.0+、PostgreSQL、SQL Server、Oracle 都支持；SQLite 3.25+ 也支持，但旧版不支持
跳过前 100 行取接下来 20 条（分页替代方案）
用 OFFSET 100 LIMIT 20 在大数据偏移时性能差，因为仍要扫描前 100 行。用 ROW_NUMBER() 预先编号后过滤，等价但更可控：
SELECT * FROM ( SELECT *, ROW_NUMBER() OVER (ORDER BY id) AS rn FROM products ) t WHERE rn BETWEEN 101 AND 120;
关键差异：
-
ORDER BY id必须明确且有索引支撑，否则ROW_NUMBER()排序开销大 -
BETWEEN 101 AND 120是闭区间，和LIMIT 20 OFFSET 100语义一致 - 如果
id不连续或有删改，用主键排序比用时间戳更稳定 - 某些数据库（如 PostgreSQL）对
LIMIT/OFFSET优化较好，但超过几万偏移后，ROW_NUMBER()方式反而更容易加索引提示
容易踩的坑：ORDER BY 缺失、NULL 值、性能误判
ROW_NUMBER() 要求必须有 ORDER BY，否则报错（如 PostgreSQL 报 window function requires an ORDER BY clause）。另外，NULL 值默认排在最前（NULLS FIRST），可能打乱你预期的“最新”逻辑：
- 显式写
ORDER BY updated_at DESC NULLS LAST避免 NULL 干扰排名 - 在
PARTITION BY字段上存在大量 NULL 时，所有 NULL 会被归为同一组，需提前WHERE col IS NOT NULL过滤 - 不要在大表上无条件用
ROW_NUMBER() OVER (ORDER BY *)—— 全局排序成本极高，优先考虑是否真需要完整编号 - 若只是去重取首行，
DISTINCT ON（PostgreSQL）或FIRST_VALUE()可能比ROW_NUMBER()更轻量
真正难的不是写出 ROW_NUMBER()，而是判断什么时候它比子查询/JOIN/CTE 更合适——核心看两点：是否需要序号本身，以及排序字段是否有高效索引。
