分页查询优化有延迟关联和游标分页两种高效方案：延迟关联先查主键再关联，减少回表；游标分页用上一页最后值替代offset，避免全表扫描。
分页查询在Web应用中非常常见，但随着数据量增长，LIMIT offset, size这类传统方式会越来越慢——尤其是当offset很大时，mysql仍需扫描并跳过前面大量行。两种高效替代方案是延迟关联（Deferred Join）和游标分页（Cursor-based Pagination），它们从原理上规避了全表扫描问题。
延迟关联：用主键减少回表开销
核心思想是先通过索引快速定位到目标页的主键集合，再用这些主键去关联原表获取完整字段。适用于有明确排序字段且该字段上有索引的场景（如按created_at DESC分页）。
示例优化前：
select * FROM orders ORDER BY created_at DESC LIMIT 100000, 20;优化后：
SELECT o.* FROM orders o INNER JOIN ( SELECT id FROM orders ORDER BY created_at DESC LIMIT 100000, 20 ) AS tmp ON o.id = tmp.id ORDER BY o.created_at DESC;说明：
- 子查询只查
id（通常是主键），走覆盖索引，不回表，速度极快； - 外层JOIN基于主键，效率高，避免了扫描10万+行；
- 必须确保
ORDER BY字段有索引，且排序方向与索引一致； - 若存在重复值（如多个订单
created_at相同），需加入id作为第二排序条件保证结果稳定。
游标分页：用“上次最后值”代替偏移量
不再依赖OFFSET，而是记录上一页最后一条记录的排序字段值（即“游标”），下一页查询时用WHERE sort_col + <code>LIMIT size。适合实时性要求高、数据写入频繁、不允许跳页的场景（如信息流、日志列表）。
示例（按时间倒序）：
-- 第一页（无游标） SELECT id, title, created_at FROM posts ORDER BY created_at DESC, id DESC LIMIT 20; <p>-- 第二页（假设上一页最后一条 created_at='2024-05-01 10:23:45', id=8892） SELECT id, title, created_at FROM posts WHERE created_at < '2024-05-01 10:23:45' OR (created_at = '2024-05-01 10:23:45' AND id < 8892) ORDER BY created_at DESC, id DESC LIMIT 20;关键点：
- 必须包含足够唯一性的排序组合（如
created_at, id），防止漏数据或重复； - 前端需保存并传递游标值（通常为base64编码的复合值），不能手动构造；
- 不支持直接跳转到第N页，但支持无限向下翻页，性能恒定；
- 新增/删除数据不影响已翻页结果，比OFFSET更稳定。
怎么选？看业务需求
延迟关联更适合后台管理类系统：需要跳转任意页、排序字段稳定、能接受少量重复或缺失（可通过唯一排序修复）。
游标分页更适合用户端Feed流：强调加载速度、滚动体验、数据实时性，且接受“只能下拉加载”这一交互约束。
补充建议：
- 无论哪种方式，都要确保排序字段有高效索引（联合索引顺序要匹配
ORDER BY）； - 避免在分页SQL中使用
SELECT *，只查必要字段； - 对超大表，可考虑归档历史数据或增加物化视图辅助分页。
不复杂但容易忽略：分页不是语法问题，而是数据访问模式问题。选对策略，百万级数据也能毫秒响应。