java中用jdbc实现分页查询的核心是将分页逻辑下推至数据库执行，而非java端截取数据，从而避免oom；具体通过数据库原生语法如mysql的limit offset, size、postgresql/oracle的offset...fetch、sql server的offset/fetch或rownum嵌套实现，并需正确管理connection、preparedstatement和resultset资源，同时校验并封装分页参数，大数据量时推荐游标分页替代大offset方案。
Java 中用 JDBC 实现分页查询，核心是让数据库只返回当前页需要的数据，而不是把全表拉进内存。这能直接规避 ResultSet 过大、JVM 堆溢出（OOM）等问题。关键不在于 Java 端“截取数据”，而在于把分页逻辑下推到数据库执行。
用数据库原生分页语法（推荐）
不同数据库的写法不同，但原理一致：由数据库完成数据筛选和裁剪，JDBC 只接收固定数量的结果行。
- MySQL：用 LIMIT offset, size，例如
SELECT * FROM user ORDER BY id LIMIT 20, 10（跳过前20条，取10条） - PostgreSQL / Oracle 12c+：用 OFFSET ... FETCH NEXT，如
SELECT * FROM user ORDER BY id OFFSET 20 ROWS FETCH NEXT 10 ROWS ONLY - SQL Server：用 TOP + NOT IN / ROW_NUMBER() 或 OFFSET/FETCH（2012+ 版本支持）
- Oracle 11g 及更早：用 ROWNUM 嵌套子查询，注意必须先排序再套 ROWNUM，否则结果不可靠
正确管理 JDBC 资源
即使用了分页，若 PreparedStatement 或 ResultSet 没及时关闭，仍可能累积句柄或内存泄漏，尤其在循环分页时。
- 每次查询后必须显式调用 rs.close() 和 ps.close()，不能依赖 finally 块延迟释放
- 使用同一个 Connection 是可行的，但不要复用 PreparedStatement——它绑定的是具体 SQL 和参数，分页参数变时需重新 prepare
- 避免在 while 循环中不断 new Connection；应复用连接池中的连接，或确保单次分页流程内 Connection 正确 close
分页参数计算与封装
页码从 1 开始，偏移量 = (pageNum − 1) × pageSize。建议封装成工具类或 DTO，防止计算错误导致查空或越界。
- 对 pageNum 和 pageSize 做校验：小于 1 的页码默认为 1；pageSize 过大（如 > 500）应限制或告警
- 可封装类似 PageRequest 的对象，提供 getOffset() 方法，业务层只传页码和页大小，DAO 层拼 SQL 时自动计算
- 总记录数查询要单独执行 count(*)，但注意避免在大数据表上频繁执行——可缓存、异步更新或改用估算值
大数据量下的补充策略
当页码极大（如第 10000 页），OFFSET 方式性能会陡降，此时需换思路：
-
游标分页（Cursor-based Pagination）：用上一页最后一条的排序字段值作为下一页起点，例如
WHERE created_time - 分批处理替代分页展示：后台导出、统计等场景，不用页码，改用 while 循环 + 固定 pageSize 查询，处理完一批就清空 List，不累积
- Sharding 场景需注意：分库分表后，全局 limit+offset 不准确，需借助 ShardingSphere 的分页合并能力，或改用基于主键/时间戳的范围分页
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
