ROW_NUMBER()不能当索引用，因为它是动态计算的逻辑序号，不存储、不可索引、无法用于WHERE过滤；正确做法是依靠联合索引+Top-N查询或带范围过滤的子查询嵌套。
ROW_NUMBER() 为什么不能当索引用
ROW_NUMBER() 是窗口函数，不是物理索引，它只在查询执行时动态计算行序号，不存储、不可复用、无法加速 WHERE 或 JOIN。你写 WHERE rn = 5（其中 rn 来自 ROW_NUMBER()）会报错，因为窗口函数不能出现在 WHERE 子句里——这是最常见的误用起点。
真正想“快速定位分组内第 N 条记录”，核心矛盾在于：窗口函数输出的是逻辑序号，而数据库引擎要靠 B+ 树索引跳过扫描。两者不在一个层面。
- 试图给
ROW_NUMBER()结果建索引？不行——多数数据库（PostgreSQL、MySQL 8.0+、SQL Server）都不允许对窗口函数表达式建索引 - 把
ROW_NUMBER()结果存成物化列再索引？PostgreSQL 支持带STORED的生成列，但 MySQL 不支持；且一旦基表更新，该列不会自动刷新，数据易 stale - 用子查询套一层再
WHERE？可以，但每次执行都得全量算一遍ROW_NUMBER()，分组大、数据多时性能断崖下跌
替代方案：用索引 + LIMIT/OFFSET 模拟分组内偏移
如果目标是“取每个分组中按某字段排序后的第 1 条/前 3 条/第 N 条”，更高效的做法是放弃 ROW_NUMBER()，改用带索引的分组内 Top-N 查询模式。前提是：分组键和排序键上有联合索引。
例如查每个 category 下价格最低的 1 条商品：
SELECT DISTINCT ON (category) * FROM products ORDER BY category, price;
这在 PostgreSQL 中高效，前提是 (category, price) 有索引；在 MySQL 8.0+ 可用 ROW_NUMBER() 配合 WHERE rn = 1（需子查询），但必须确保 PARTITION BY category ORDER BY price 能走索引——否则照样慢。
- MySQL 要让
PARTITION BY a ORDER BY b走索引，必须存在(a, b)前缀索引；(b, a)不行 - SQL Server 的
TOP (1) WITH TIES配合OVER (PARTITION BY ... ORDER BY ...)在某些场景下能避免全窗口计算，但依然依赖索引覆盖 - 别在没索引的字段上
ORDER BY——此时ROW_NUMBER()会强制 sort，内存溢出或磁盘 spool 风险陡增
真要靠 ROW_NUMBER() 定位？只能接受子查询嵌套成本
当业务逻辑硬性要求“分组内第 N 条”且 N 不固定（比如参数化输入），又无法重构为 Top-N 模式时，唯一可落地的方式是两层子查询：外层过滤序号，内层计算序号。但必须加约束防止爆炸。
SELECT * FROM (
SELECT *, ROW_NUMBER() OVER (
PARTITION BY user_id ORDER BY created_at DESC
) AS rn
FROM events
WHERE created_at >= '2024-01-01' -- 先缩小范围！
) t
WHERE rn = 3;
- 务必在内层加
WHERE过滤主键范围、时间范围或状态字段，避免全表扫再算窗口 - PostgreSQL 中可考虑用
LATERAL关联单条，比窗口函数更轻量，例如对每个user_id执行一次SELECT ... ORDER BY ... LIMIT 1 OFFSET 2 - SQL Server 2022+ 支持
OFFSET-FETCH在 APPLY 中使用，也能绕开大窗口
最容易被忽略的性能陷阱：ORDER BY 字段 NULL 值处理
ROW_NUMBER() 的排序结果直接受 NULLS FIRST / NULLS LAST 影响，而默认行为各库不同：PostgreSQL 默认 NULLS FIRST，MySQL 和 SQL Server 当作最小值（即 NULLS LAST 效果）。如果你的排序字段有大量 NULL，又没显式声明，分组内序号可能和预期完全错位。
- 显式写
ORDER BY updated_at DESC NULLS LAST（PostgreSQL）或ORDER BY IFNULL(updated_at, '1970-01-01') DESC（MySQL）保持语义一致 - 索引对
NULL的处理也不同：B+ 树索引是否包含NULL值项，影响能否命中；MySQL 的二级索引天然存NULL，PostgreSQL 需要INCLUDE或单独条件索引 - 测试时用含
NULL的小数据集跑一遍，别等上线后发现第 1 条总是错的
实际线上遇到的慢查询，八成不是 ROW_NUMBER() 写错了，而是没意识到它背后没有索引支撑，还把它当成了“分组内 ID”。真要低延迟定位，优先想怎么设计索引和重写查询逻辑，而不是调参或换写法。
