row_number() 必须位于最外层select中，不可直接用于子查询select列表，否则报错；正确做法是通过cte或派生表提前计算，再在外层应用，且需确保order by字段在结果集中存在。
ROW_NUMBER() 必须出现在最外层 SELECT 中，且不能直接套在子查询的 SELECT 列表里——否则会报错 Window function is not allowed in this context。
嵌套查询中 ROW_NUMBER() 的位置限制
SQL 标准和主流数据库（PostgreSQL、SQL Server、Oracle、Snowflake）都禁止在子查询的 SELECT 子句中直接使用窗口函数。比如下面写法一定失败：
SELECT id, name, (SELECT ROW_NUMBER() OVER (ORDER BY created_at) FROM orders o WHERE o.user_id = u.id) FROM users u;
这是因为窗口函数依赖于当前查询的完整结果集，而子查询无法“看到”外层的排序上下文。
- 正确做法是把嵌套逻辑提前到 CTE 或派生表中，再在外层应用
ROW_NUMBER() - 如果嵌套涉及多层 JOIN 或 FILTER，先用 CTE 拆解业务逻辑，避免在
OVER()中写复杂表达式 - MySQL 8.0+ 和 PostgreSQL 支持在派生表中直接用窗口函数，但 SQL Server 要求必须是“顶层”
SELECT
多级分组排序时 ORDER BY 的实际影响范围
ROW_NUMBER() OVER (ORDER BY ...) 的排序只作用于当前窗口帧，不改变原始数据顺序。若嵌套查询本身含 ORDER BY（如子查询带 LIMIT），它和窗口的 ORDER BY 是两回事。
- 例如：CTE 中按
category分组取 Top 3，外层再按sales DESC编号——两个ORDER BY独立生效 - 如果漏写
PARTITION BY，ROW_NUMBER()会对整个结果集连续编号，可能掩盖分组意图 - 在
OVER()中混用表达式（如ORDER BY COALESCE(price, 0)）要确保该列在嵌套结果中已存在，否则报column does not exist
性能敏感场景下的替代方案
当嵌套查询本身就很慢，再加 ROW_NUMBER() 可能放大延迟，尤其在没有合适索引的 ORDER BY 字段上。
- 先确认嵌套查询的执行计划是否走索引；若
ORDER BY字段未索引，ROW_NUMBER()会强制全局排序，代价陡增 - 如果只是需要“唯一 ID”而非严格序号，可改用
GENERATE_SERIES()（PostgreSQL）或ROWID（Oracle），避开窗口函数开销 - 对超大数据集，考虑在应用层分页（如用
OFFSET/LIMIT+ 前一页最大值作为游标），比全量编号更可控
真正容易被忽略的是：嵌套查询若含聚合（如 GROUP BY），必须确保 ROW_NUMBER() 所依赖的排序字段在 SELECT 列表中出现，否则某些数据库（如 SQL Server）会直接拒绝执行。
