一、传统分页的问题
LIMIT OFFSET性能瓶颈
当查询SELECT * FROM table LIMIT N OFFSET M时，MySQL需要扫描前M+N行数据，丢弃前M行，导致偏移量越大性能越差，尤其在百万级数据场景下延迟显著
二、优化方案
1. 基于游标的分页（Cursor-based Pagination）
原理记录上一页最后一条记录的标识（如主键），下次查询直接定位到该位置，避免全表扫描¹²⁴⁶⁷⁸。适用场景
按唯一且有序的字段（如自增ID、时间戳）排序的分页。示例
-- 第一页 SELECT * FROM table ORDER BY id DESC LIMIT 10; -- 第二页（假设上一页最后一条id=100） SELECT * FROM table WHERE id < 100 ORDER BY id DESC LIMIT 10;
2. 覆盖索引优化（Covering Index）
原理仅通过索引即可完成查询，无需回表读取数据行，减少I/O开销。示例
-- 普通分页（慢） SELECT * FROM table ORDER BY id LIMIT 100000, 10; -- 覆盖索引优化（快） SELECT * FROM table INNER JOIN (SELECT id FROM table ORDER BY id LIMIT 100000, 10) AS tmp USING (id);
3. 子查询优化
原理先通过子查询获取分页主键，再用主键关联原表，减少数据扫描量¹²⁴⁶⁷⁸。示例
SELECT * FROM table WHERE id >= (SELECT id FROM table ORDER BY id LIMIT 100000, 1) ORDER BY id LIMIT 10;
4. 延迟关联（Deferred Join）
原理先通过索引获取主键，再关联主表查询完整数据，减少大偏移量的资源消耗²⁴⁶⁷⁸。示例
SELECT * FROM table INNER JOIN (SELECT id FROM table ORDER BY id LIMIT 100000, 10) AS tmp ON table.id = tmp.id;
5. 预计算分页数据
原理使用缓存（如Redis）存储热点页数据，或定期生成静态分页结果²⁶⁷⁹。适用场景
数据更新频率低的场景，如历史记录、归档数据。
三、性能对比
四、注意事项
1、索引设计
排序字段必须建立索引（单字段或复合索引）。避免ORDER BY与WHERE条件索引冲突导致全表扫描。2、数据一致性
游标分页需确保排序字段唯一，否则可能出现重复或遗漏。高并发写入场景下，分页结果可能因数据变动出现偏差，需权衡实时性。3、业务适配
游标分页不支持跳页，需前端记录游标位置。若需多字段排序，需建立复合索引并测试性能。五、总结
小数据量场景：直接使用LIMIT OFFSET，简单易用。大数据量场景：- 优先选择游标分页，性能最优。若需兼容跳页，使用子查询优化或延迟关联。结合业务设计缓存策略，减少实时查询压力。
以上就是MySQL快速分页查询的优化方案的详细内容，更多关于MySQL快速分页查询优化的资料请关注其它相关文章！
