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()，那是给自己留了个定时性能炸弹。
