ROW_NUMBER()分页在大数据量下变慢，因其需全表排序编号，即使只取后几页也要计算全部序号，导致I/O和内存压力剧增；游标分页通过记录上一页末尾排序键值实现索引范围扫描，避免全量计算。

ROW_NUMBER() 分页在大数据量下为什么变慢

因为 ROW_NUMBER() 必须对全表或全结果集排序并编号，哪怕你只要第 100 万页的 20 条数据，它也得先算出前 100 万 × 20 行的序号。磁盘 I/O 和内存压力会指数级上升，执行计划里常见 Sort 操作占 90%+ 时间。

• 数据量超 500 万行后，ORDER BY created_at, id + ROW_NUMBER() 分页响应常超 10 秒
• 如果 ORDER BY 字段没索引，性能断崖式下跌，甚至触发磁盘临时表
• 视图里封装了 ROW_NUMBER() 并不改变底层执行逻辑——查询时仍要全量计算

用游标分页（Cursor Pagination）替代 OFFSET/LIMIT

本质是“记住上一页最后一条的排序键值”，下一页直接 WHERE (sort_col, id) > (last_value, last_id)，跳过所有已扫描行。数据库能走索引范围扫描，避免 OFFSET 跳过大量数据。

• 必须有确定性排序：至少两个字段组合（如 created_at DESC, id DESC），防止时间相同导致顺序不稳
• 首次请求用 WHERE created_at
• 后续请求带游标：WHERE (created_at, id)
• 视图不能直接参数化游标值，需在外部 SQL 中拼接或用存储过程传参

视图里硬写 ROW_NUMBER() 的陷阱

很多人建视图时直接包一层 ROW_NUMBER() OVER (ORDER BY ...)，以为能复用。实际每次查询该视图都会重算整列，且无法下推过滤条件——比如 SELECT * FROM my_view WHERE rn BETWEEN 1000001 AND 1000020，数据库仍要生成全部行号再过滤。

• 视图定义中含 ROW_NUMBER() 会导致执行计划出现 WindowAgg 节点，无法被索引优化覆盖
• 即使外层加 WHERE，PostgreSQL/SQL Server 通常不会自动剪枝；MySQL 8.0+ 有部分优化但不可依赖
• 正确做法是把核心查询逻辑放视图里（不含 ROW_NUMBER()），分页逻辑交给调用方用游标或延迟关联实现

偏移量分页还能抢救吗？加覆盖索引试试

如果必须用 OFFSET（比如第三方分页组件强绑定），唯一靠谱的补救是让排序字段和查询字段都在一个索引里，避免回表。否则 OFFSET 1000000 意味着数据库要定位到第 100 万行、再回原表取数据，IO 成倍放大。

• 建联合索引：CREATE INDEX idx_list_cover ON orders (status, created_at, id) INCLUDE (user_id, amount);（SQL Server / PostgreSQL）
• MySQL 需用 INDEX(status, created_at, id, user_id, amount)，注意长度限制
• 确保 WHERE 条件能命中索引最左前缀，否则覆盖索引无效
• 即便如此，OFFSET 超过 10 万后延迟仍明显，仅适合过渡期或低频后台任务

游标分页不是银弹——它要求前端保存并传递游标值，且不支持跳转任意页。但对大数据量列表流式加载，这是目前最可控的路径。别在视图里埋 ROW_NUMBER()，那是给自己留了个定时性能炸弹。