SQL分页变慢主因是OFFSET导致数据库全扫并丢弃大量数据，产生I/O与CPU双重开销；游标分页通过排序键值范围过滤替代OFFSET，实现稳定高效查询。
SQL分页查询变慢，核心原因不是“OFFSET 越大越慢”这个表象，而是数据库执行计划中跳过大量已扫描但不返回的数据带来的双重开销：I/O 扫描成本 + CPU 过滤成本。尤其在深度分页（如 OFFSET 1000000 LIMIT 20）时，问题会急剧放大。
OFFSET 的真实代价：全扫+丢弃
MySQL、PostgreSQL 等主流数据库在使用 OFFSET 时，并不会“直接跳到第 N 行”，而是从头开始顺序扫描，逐行计数，直到跳过前 N 行，再取后续结果。这意味着：
- OFFSET 100 万时，即使只要 20 行，数据库仍需定位并读取至少 1000020 行（含索引页和数据页）
- 若排序字段无有效索引，还要额外触发 filesort 或临时表，性能雪崩
- 高并发下，重复扫描加剧 Buffer Pool 压力，影响其他查询
为什么 LIMIT M,N 比 LIMIT N 更难优化？
数据库优化器对 LIMIT N（即 LIMIT 0,N）可结合索引快速截断；但 LIMIT M,N 隐含“必须精确跳过 M 行”，无法利用索引的有序性直接定位起点。即使有复合索引 (order_col, id)，优化器也常因统计信息不准或谓词复杂而放弃索引覆盖扫描，回落到全表扫描+排序。
例如：
SELECT * FROM orders ORDER BY created_at DESC LIMIT 1000000, 20;
即使 created_at 有索引，MySQL 仍可能先用索引查出前 1000020 条主键，再回表取数据——回表次数翻倍，缓冲区争用加剧。
真正有效的替代方案：游标分页（Cursor-based Pagination）
绕过 OFFSET 的根本办法，是用“上一页最后一条记录的排序键值”作为下一页查询条件，把 位置偏移 转为 值范围过滤：
- 第一页：
SELECT * FROM orders WHERE status = 'paid' ORDER BY created_at DESC, id DESC LIMIT 20; - 第二页（假设上一页最后一条是
created_at='2024-05-01 10:22:33', id=8892）：SELECT * FROM orders WHERE status = 'paid' AND (created_at < '2024-05-01 10:22:33' OR (created_at = '2024-05-01 10:22:33' AND id < 8892)) ORDER BY created_at DESC, id DESC LIMIT 20; - 该方式始终走索引范围扫描，执行时间稳定，与总数据量无关
其他实用优化手段
若必须用 OFFSET（如后台管理搜索页），可结合以下策略缓解：
-
强制覆盖索引：只 SELECT 索引列（如主键或排序字段），避免回表。例如：
SELECT id FROM orders ORDER BY created_at DESC LIMIT 1000000, 20，再用 ID 批量 JOIN 取详情 -
延迟关联（Deferred Join）：先用索引快速获取主键，再关联原表。适用于 MySQL：
SELECT o.* FROM orders o INNER JOIN (SELECT id FROM orders ORDER BY created_at DESC LIMIT 1000000, 20) AS tmp ON o.id = tmp.id; -
预生成分页映射表：对静态或低频更新的大表，可定时维护一张
page_offset → min_id/max_id映射表，将深度分页转为区间查询
