row_number() 必须配合 partition by 和 order by 才能实现每组 top n；单独 order by 仅生成全局序号；漏 partition by 是常见错误；需确保分组字段唯一、排序字段确定；并列需求应选 rank()；where 不可直接过滤 row_number() 别名。
ROW_NUMBER() 必须配合 PARTITION BY 和 ORDER BY 才能正确分组取 Top N
单独用 ROW_NUMBER() OVER(ORDER BY score DESC) 只会给全表打一个全局序号，根本不是“每类 Top N”。业务中真正需要的是“每个部门工资最高的 3 人”或“每个用户最近下单的 2 笔”，这必须靠 PARTITION BY department_id 切分逻辑组，再在组内用 ORDER BY created_at DESC 排序。漏掉 PARTITION BY 是初学者最高频的错误。
实操建议：
- 先确认分组字段是否真正唯一标识业务单元（比如
user_id而不是模糊的username） -
ORDER BY里务必包含确定性排序字段（如加id防止相同时间戳导致结果不稳定） - 如果业务要求“并列不跳号”，
ROW_NUMBER()不适用，得换RANK()或DENSE_RANK()
WHERE 子句不能直接过滤 ROW_NUMBER() 别名，必须嵌套子查询或 CTE
写成 SELECT *, ROW_NUMBER() OVER(...) AS rn FROM orders WHERE rn 会报错：<code>Invalid column name 'rn'。因为 SQL 执行顺序是 WHERE → GROUP BY → SELECT，rn 在 WHERE 阶段还不存在。
实操建议：
- 用子查询：
SELECT * FROM (SELECT *, ROW_NUMBER() OVER(PARTITION BY user_id ORDER BY created_at DESC) AS rn FROM orders) t WHERE t.rn
- 用 CTE 更清晰：
WITH ranked AS (SELECT *, ROW_NUMBER() OVER(PARTITION BY user_id ORDER BY created_at DESC) AS rn FROM orders) SELECT * FROM ranked WHERE rn
- 别在子查询里多选无用字段——
ROW_NUMBER()本身不耗性能，但传输和处理冗余列会拖慢整体响应
ORDER BY 中 NULL 值处理不当会导致 Top N 结果意外偏移
默认情况下，ORDER BY score DESC 会把 NULL 排在最前面（SQL 标准行为），如果业务中 score 允许为空，那 “Top 3” 很可能返回一堆 NULL 记录，而非真实高分数据。
实操建议：
- 显式控制 NULL 位置：用
ORDER BY score DESC NULLS LAST（PostgreSQL / Oracle 支持） - 兼容 MySQL（无
NULLS LAST）：改用ORDER BY IFNULL(score, -999999) DESC或ORDER BY score IS NULL, score DESC - 更稳妥的做法是在业务层过滤掉无效记录（如
WHERE score IS NOT NULL），避免语义歧义
大数据量下 ROW_NUMBER() 性能断崖下跌，优先考虑物化中间结果
当源表超千万行、分区键基数高（比如 PARTITION BY user_id 有百万级不同值），ROW_NUMBER() 会强制对每个分区做完整排序，I/O 和内存压力陡增，查询可能从秒级变成分钟级。
实操建议：
- 给
PARTITION BY字段 +ORDER BY字段建联合索引（如(user_id, created_at)） - 若 Top N 是高频固定需求（如“每日各品类销量 Top 10”），用定时任务预计算并存入宽表，避免实时计算
- MySQL 8.0+ 可尝试用
LIMIT配合窗口函数优化器提示（但效果有限），不如直接降级为分组聚合 + 自连接模拟
真正难的不是写出语法正确的 ROW_NUMBER()，而是想清楚“分组依据是否符合业务边界”“排序字段是否具备业务意义”以及“NULL 和性能问题是否已在数据源头被约束”。这些地方一松动，结果就不可信。
