OFFSET 越大查询越慢是因为 MySQL 需扫描并丢弃前 N 行，时间复杂度为 O(N)；应改用游标（seek）分页，基于上一页末尾排序字段值做条件查询，并确保索引匹配、游标值服务端生成与校验。
为什么 OFFSET 越大查询越慢
MySQL 的 OFFSET 不是跳过前 N 行再取数据，而是让引擎先扫描并丢弃前 N 行——哪怕你只想要 1 条记录，OFFSET 1000000 也会真实执行 1000001 行的主键或索引遍历。InnoDB 的聚簇索引顺序扫描 + 逐行计数，本质是 O(N) 时间复杂度，不是 O(1) 跳转。
常见错误现象：SELECT * FROM orders ORDER BY id LIMIT 20 OFFSET 1000000 延迟飙升到秒级甚至超时；EXPLAIN 显示 rows 极高，且 Extra 出现 Using filesort 或 Using index 但扫描行数远超 LIMIT 值。
用游标（seek）替代 OFFSET 的核心写法
seek 方法不依赖行号偏移，而是利用上一页最后一条记录的排序字段值作为下一页的起点条件。前提是排序字段必须有唯一性保障（如主键、或联合唯一索引），否则可能漏行或重复。
- 假设分页字段是
id（主键递增），第一页查完后拿到最后一条的id = 1024，第二页就该写成：SELECT * FROM orders WHERE id > 1024 ORDER BY id LIMIT 20 - 如果排序字段不是主键（比如
created_at），且存在时间相同的情况，必须补上唯一字段去重：WHERE (created_at, id) > ('2024-05-01 10:00:00', 5000) ORDER BY created_at, id LIMIT 20 - 倒序分页同理，用
：上一页最后一条是id = 9876，下一页就是WHERE id
ORDER BY 字段没索引？先建索引再谈 seek
seek 方法的前提是 WHERE 条件能走索引。如果 ORDER BY created_at 没索引，WHERE created_at > ? 会全表扫描，比 OFFSET 还糟。
检查方式：EXPLAIN SELECT * FROM orders WHERE created_at > '2024-01-01' ORDER BY created_at LIMIT 20，确认 key 列非 NULL 且 rows 接近 LIMIT 值。
- 单字段排序：直接建
INDEX(created_at) - 多字段排序（含主键）：建联合索引，顺序必须和
ORDER BY一致，例如ORDER BY status, updated_at, id→INDEX(status, updated_at, id) - 注意：如果
WHERE里还有其他等值条件（如WHERE category = 'A'），应把等值字段放在联合索引最左列
客户端如何安全维护游标值
游标值（比如上一页最后一个 id）不能靠前端传来的“页码”计算，必须由服务端在查出结果后显式提取并返回给前端，前端仅作透传。否则用户手动改 URL 里的 last_id=123 可能跳过数据或重复。
容易踩的坑：
- 没处理空结果：当某页查不到数据（如被删光），仍返回上一个游标，会导致无限循环或 500 错误；应检测
result.length === 0并终止分页 - 并发更新风险：如果新记录插入在游标值之前（比如按时间倒序，新订单时间更早），用户可能跳过这条记录；这是 seek 的固有限制，无法完全规避，只能接受“最终一致性”语义
- 不要混用 offset 和 seek：同一业务逻辑中切勿一部分用
OFFSET，一部分用游标，状态难以对齐
真正麻烦的从来不是写法，而是游标值从数据库出来之后，在哪存、谁负责校验、怎么应对删除/插入导致的错位——这些细节比 SQL 多得多。
