row_number() 性能瓶颈源于 over() 中 order by 强制全量排序，无论是否只需首行；分区多、字段无索引或含函数时开销剧增，嵌套查询中更会放大排序规模。
ROW_NUMBER() 的排序开销来自 OVER() 内部的 ORDER BY
根本原因不是 ROW_NUMBER() 本身，而是它强制要求的 ORDER BY 子句必须执行完整排序。数据库无法跳过这一步——哪怕你只想要第 1 行，它也得先把整个分区内的所有行按指定字段排好序，再从头编号。
PARTITION BY 越多、数据越散，排序压力越大
分区数直接影响排序并发粒度和内存占用：
- 如果
PARTITION BY字段基数很高（比如user_id有百万级唯一值），就会生成百万个独立小窗口，每个窗口都要单独做一次小排序——CPU 和内存调度开销叠加，比单次大排序更伤 - 如果分区字段存在大量 NULL 或低区分度值（如
status IN ('active', 'inactive')），会导致少数几个超大分区，排序时容易撑爆 sort buffer，触发磁盘临时文件（Using temporary; Using filesort） - MySQL 8.0+ 和 PostgreSQL 会尝试并行窗口排序，但前提是分区足够大且系统资源充足；小分区反而因线程调度损耗更大
ORDER BY 字段没索引，性能直接崩
ROW_NUMBER() 的 ORDER BY 不走普通查询索引，它需要的是“能支撑窗口内快速排序”的索引结构：
- 复合索引必须严格匹配
PARTITION BY + ORDER BY字段顺序，例如PARTITION BY uid, dept_id ORDER BY create_time DESC，对应索引应为(uid, dept_id, create_time DESC) - 仅对
create_time单独建索引无效——数据库仍需回表取出所有分区数据再排序 - 如果
ORDER BY包含表达式（如ORDER BY UPPER(name)）或函数，索引完全失效，必然全表扫描 + 文件排序
嵌套子查询里用 ROW_NUMBER() 容易放大问题
常见写法：SELECT * FROM (SELECT *, ROW_NUMBER() OVER (...) AS rn FROM t WHERE ...) t2 WHERE rn = 1 看似只取 Top 1，实际执行顺序是：
- 先执行
WHERE过滤 - 再对过滤结果做全部分区 + 全量排序（不管你要不要第 1 行）
- 最后才过滤
rn = 1
这意味着：哪怕最终只返回 10 行，中间可能已对百万行完成排序。真正省资源的做法是把过滤条件尽量前移，或改用 LIMIT 1 配合 GROUP BY（当语义允许时）。
真正卡住性能的，往往不是语法写错，而是默认以为“只取一行就快”，却忽略了窗口函数底层必须完成的全分区排序动作。尤其在分页、去重、最新记录提取这类高频场景里，不看执行计划、不建对索引，ROW_NUMBER() 很容易变成慢查询的隐形推手。
