大表分页查询慢的核心在于SQL的LIMIT offset, size导致数据库扫描丢弃大量数据；应优先采用游标分页（基于上一页末尾主键或时间戳），辅以延迟关联、覆盖索引、业务限制等策略优化。
大表分页查询慢，核心问题不在 Java 本身，而在 SQL 执行逻辑——LIMIT offset, size 中的 offset 越大，数据库越要扫描并丢弃前 offset 行。Java 层要做的是配合数据库优化策略，避免“硬扛”深分页。关键不是换框架，而是改思路。
用游标分页替代 OFFSET
这是最有效、最常用的优化方式。不依赖页码跳转，而是记住上一页最后一条记录的主键（或时间戳），下一页直接从该值之后取数据。
- 初始查第一页：
SELECT id, name, created_time FROM orders ORDER BY id DESC LIMIT 20 - 第二页（假设上一页最小 id 是 987654）：
SELECT id, name, created_time FROM orders WHERE id < 987654 ORDER BY id DESC LIMIT 20 - Java 中只需把上一页末尾 id 作为参数传入下一次请求，无需计算偏移量
- 必须确保排序字段有索引（如
PRIMARY KEY(id)或INDEX(created_time)），否则性能无改善
先查 ID 再关联主表（延迟关联）
当必须支持任意页跳转（比如带页码输入框），且无法改前端交互时，可拆成两步：先快速定位目标页的主键集合，再用这些 ID 查完整数据。
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 第一步（轻量）：
SELECT id FROM orders WHERE status = 1 ORDER BY id LIMIT 1000000, 20 - 第二步（精准）：
SELECT * FROM orders WHERE id IN (1000001, 1000002, ..., 1000020) - Java 中可用
PreparedStatement拼接 IN 参数，或用 MyBatis 的<foreach>；注意 IN 列表不宜过长（一般不超过 1000 个） - 前提是 WHERE 条件能走索引，否则第一步仍慢
建覆盖索引减少回表
如果查询字段固定且不多，让数据库只读索引不查行数据，能极大降低 I/O。
立即学习“Java免费学习笔记（深入）”；
- 例如常查
id, username, email, create_time，就建联合索引：CREATE INDEX idx_user_cover ON users(id, username, email, create_time) - 对应 SQL 改为明确指定字段：
SELECT id, username, email, create_time FROM users ORDER BY id LIMIT 1000000, 20 - 避免
SELECT *，尤其不要在深分页中查大文本字段（如TEXT,JSON）
业务层做限制与引导
技术优化之外，产品和架构层面的约束同样重要。
- 后端校验：对
pageNo > 1000或offset > 100000的请求直接拒绝，返回友好提示 - 前端配合：禁用“跳转到第 N 页”输入框，只提供“下一页/上一页”按钮，推动用户使用游标模式
- 加筛选条件：默认强制带时间范围（如最近 30 天）、状态、分类等，大幅缩小数据集基数
- 高频分页结果可缓存（如 Redis 存前 100 页的 ID 列表），但需注意数据实时性要求
