mysql大分页查询慢的根本原因是limit offset, size在offset很大时需扫描并丢弃大量数据；优化方案包括延迟关联（子查询查主键再join）和游标分页（基于排序字段值续查），java层应配合做缓存、超时控制及前端限制。
MySQL大分页查询慢，根本原因不是Java代码写得不好，而是LIMIT offset, size在offset很大时，数据库必须扫描并丢弃前offset行——哪怕只返回10条数据，也可能要读上百万行。Java层能做的，是配合数据库策略规避这个问题，而不是硬扛。
用延迟关联减少无效扫描
这是最实用、改动最小的优化方式，适合仍需支持“跳页”（比如后台输入页码）的场景。
- 先确保排序字段和查询条件上有合适的覆盖索引，例如按
status = ? AND created_at DESC分页，索引应建为INDEX(status, created_at, id)——顺序不能错，id放最后才能让子查询走索引不回表 - SQL改写成两层：子查询只查主键id，外层用主键JOIN取全量数据
SELECT t1.* FROM orders t1 INNER JOIN (SELECT id FROM orders WHERE status = 1 ORDER BY created_at DESC LIMIT 1000000, 20) t2 ON t1.id = t2.id; - 注意别踩坑：子查询里不能写
SELECT *或非索引字段；JOIN必须是ON t1.id = t2.id这种等值主键关联；如果业务字段太多导致索引过宽，反而影响定位效率，这时就得考虑换方案
切换游标分页彻底绕开offset
这是性能最稳、扩展性最好的方案，适合“下一页”式滚动加载（如App列表、后台无限加载），但不支持直接跳到第500页。
- 核心是记住上一页最后一条记录的排序字段值，作为下一页的查询起点。例如按id降序：
SELECT * FROM orders WHERE id - 排序字段必须唯一且有索引，推荐组合
(created_at, id)防时间重复；并发插入或删除可能导致漏/重，可在Java层加简单校验，比如检查返回首尾id是否落在合理时间窗口内 - Java里只需把上一页末尾的
id或created_at + id作为参数传入下一次查询，完全不用算offset，也不依赖页码
Java层做轻量协同优化
数据库优化之外，应用层也能降低抖动感知和失败风险。
- 对高频深度分页结果做缓存，比如第1000页的结果缓存5分钟，避免重复执行慢查询
- MyBatis或JdbcTemplate配置
queryTimeout，防止一个深分页拖垮整个线程池 - 前端限制可翻页范围，例如只允许翻到前200页；或当
page × size > 100万时，后端自动切到游标模式并返回提示
什么时候该放弃分页？
不是所有场景都适合“一页页翻”。如果用户真要查第10万页的数据，大概率不是在浏览，而是在找某条特定记录。
- 优先引导用户用搜索、筛选、时间范围等精准条件替代翻页
- 管理后台可默认展示最新N条+搜索框，把“翻到底”变成异常路径而非主流程
- 导出类需求别用分页查，改用游标分批拉取+异步生成文件
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
