核心思路是将分页逻辑下推至数据库层，避免java端全量加载数据导致oom；需校验页码与页大小、显式释放资源，并在大数据量时采用游标分页替代偏移量分页。
核心思路很明确：不让全量数据进 JVM 堆，而是让数据库只吐出当前页要的数据。分页不是 Java 做的“截取”，而是数据库做的“裁剪”。内存溢出（OOM）往往就发生在你忘了这点，把几十万条记录一股脑 load 进 List。
用数据库原生分页语法，别在 Java 里截 List
Java 端拿到 ResultSet 后再用 subList 或流式 skip/take，等于已经把全部数据加载进内存——这是典型误区。必须把分页逻辑下推到 SQL 层。
- MySQL：用 LIMIT offset, size，例如
SELECT * FROM order WHERE status = 1 ORDER BY create_time DESC LIMIT 0, 50 - PostgreSQL / Oracle 12c+：用 OFFSET ... FETCH NEXT ... ROWS ONLY，排序字段必须有索引，否则性能崩
- SQL Server（2012+）：用 OFFSET ... ROWS FETCH NEXT ... ROWS ONLY
- Oracle 11g 及更早：用 ROWNUM 嵌套子查询，注意外层不能直接写
ROWNUM > 20，必须先排序再套一层
参数校验与偏移量安全计算
页码和页大小是用户输入，不校验就可能传入负数、超大 pageSize 或极大 pageNum，导致 SQL 执行慢甚至拖垮数据库。
- 页码从 1 开始，偏移量统一按 (pageNum − 1) × pageSize 计算
- pageNum ≤ 0 → 强制设为 1；pageSize ≤ 0 或 > 500 → 截断为默认值（如 20）或抛业务异常
- 封装成 PageRequest 类，提供 getOffset() 方法，DAO 层只接收该对象，避免重复计算出错
资源必须显式释放，尤其循环分页时
即使用了分页，若 PreparedStatement 或 ResultSet 没关，连接池耗尽、句柄泄漏、内存缓慢上涨都会发生，特别是后台导出任务中循环查多页。
- 每次查询后立即调用 rs.close() 和 ps.close()，不要依赖 finally 延迟释放
- Connection 可复用（推荐走连接池），但 PreparedStatement 不能跨页复用——参数变了就得重新 prepare
- 禁止在 while 分页循环里 new Connection；用 try-with-resources 包裹 PreparedStatement + ResultSet 最稳妥
大数据量场景优先选游标分页，避开深分页陷阱
当 pageNum 达到上万、offset 超过 10 万时，MySQL 的 LIMIT 会扫描前 N+size 行再丢弃，性能断崖下跌。这时偏移量分页已失效。
- 改用基于索引字段的游标分页（Keyset Pagination）：比如上一页最后一条记录的 create_time 和 id 已知，下一页查
WHERE create_time ? OR (create_time = ? AND id - 要求排序字段绝对唯一或组合唯一，避免漏数据或重复；主键或时间+ID 组合最常用
- 前端不再传 pageNum，而是传上一页末尾的游标值（如 last_time=2026-08-01T10:30:00&last_id=99999）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
