深度分页性能骤降源于offset机制缺陷，优化关键在于重构查询逻辑：优先用游标分页（基于唯一排序字段），次选延迟关联+覆盖索引，辅以业务层限制与导出优化。
深度分页（比如 LIMIT 1000000, 20）在 Java 应用中连 MySQL 时，性能骤降不是数据库“不行”，而是传统 OFFSET 机制本身有根本性缺陷：MySQL 必须扫描并丢弃前 100 万行，再取 20 行——IO、CPU、网络全被浪费。Java 层若只做简单封装（如 MyBatis 的 RowBounds 或 PageHelper），反而会放大问题。优化关键不在 Java 代码写法，而在于**重构查询逻辑 + 合理协同数据库能力**。
用游标分页替代 offset 分页（最推荐）
适用于“下一页/上一页”连续翻页场景（如列表无限滚动、后台日志流），不支持跳转任意页码，但性能跃升最显著。
- Java 层需保存上一页最后一条记录的排序字段值（如主键
id或时间戳create_time），作为下次请求参数传入 - SQL 改为带条件过滤+LIMIT，例如：
SELECT * FROM order WHERE id > ? ORDER BY id LIMIT 20 - MyBatis 中可直接用
#{lastId}绑定，无需动态拼 SQL；Spring Data JPA 可用Pageable配合@Query自定义语句 - 注意：必须确保排序字段唯一且严格递增（推荐用自增主键或
id + create_time组合防重复）
延迟关联 + 覆盖索引（通用性强，适合随机跳页）
当业务仍需支持“跳到第 500 页”这类操作时，这是目前最稳妥的方案，核心是让 MySQL 少扫描、少回表。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 先建覆盖索引（含排序字段 + 主键），例如：
ALTER TABLE order ADD INDEX idx_status_created_id (status, created_time, id); - Java 中执行两步查询（或用子查询一次性完成）：
①SELECT id FROM order WHERE status = ? ORDER BY created_time, id LIMIT ?, 20→ 只走索引，极快
② 用这些id批量查完整数据：SELECT * FROM order WHERE id IN (?, ?, ...) - MyBatis 可用
<foreach></foreach>拼IN列表；注意控制IN数量（建议 ≤ 500），超量可拆成多次查询
业务层限制与引导（低成本见效快）
很多“深度分页需求”其实来自产品设计惯性，并非真实用户行为。Java 后端可主动干预：
- 对管理后台类系统，加页码上限（如最多查到第 200 页），超限时返回提示：“数据量过大，建议按时间/状态筛选后再查”
- 前端分页组件禁用“跳转页码”输入框，只保留“上一页/下一页”按钮，后端强制走游标逻辑
- 导出类场景（如导出全部订单），不要用分页循环查，改用流式读取（
Statement.setFetchSize(Integer.MIN_VALUE)）或分段时间范围查询（如按天查）
其他辅助手段（按需选用）
这些不解决根本，但在特定场景能缓解压力：
-
预计算分页书签：定时任务提前算好每页的起始
id，存入缓存（Redis）或汇总表，Java 查询时直接查书签再定位，适合冷数据或报表类场景 -
分区表 + 时间范围过滤：若数据有明显时间属性（如订单按月分区），Java 请求时强制带上
created_date BETWEEN ? AND ?，大幅缩小扫描基数 -
ES 或物化视图兜底：对高并发、低一致性要求的搜索型分页（如商品列表），把数据同步到 Elasticsearch，用
search_after实现毫秒级深分页
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
