Java中JDBC流式查询处理百万级数据的核心是边取边处理、不缓存全量结果；需设fetchSize=Integer.MIN_VALUE、关自动提交、用游标分页、严格管理资源生命周期，并搭配流式文件写入与异步化导出。
Java 中用 JDBC 流式查询处理百万级数据，核心是避免一次性把全部结果加载进内存，而是边取边处理。关键不在“查得多”，而在“不存全量”。
启用流式结果集（MySQL 为例）
MySQL 的 JDBC 驱动默认会将整个结果集缓存在客户端内存中。必须显式配置 Statement 或 PreparedStatement 才能启用流式读取：
- 设置 fetchSize = Integer.MIN_VALUE（MySQL 特定语义，表示流式）
- 关闭自动提交（
connection.setAutoCommit(false)），防止驱动内部做额外缓冲 - 确保使用
executeQuery()而非批量操作
示例代码片段：
Connection conn = dataSource.getConnection();Statement stmt = conn.createStatement();
// 关键：触发流式读取
stmt.setFetchSize(Integer.MIN_VALUE);
ResultSet rs = stmt.executeQuery("SELECT id, name, amount FROM orders WHERE status = 'done'");
while (rs.next()) {
// 每次只从网络/数据库拉一行，不缓存整表
long id = rs.getLong("id");
String name = rs.getString("name");
// → 直接写入文件、发消息、聚合统计等
}
配合游标分页避免 OFFSET 性能退化
单纯靠 LIMIT/OFFSET 分页在百万级数据下会越来越慢（因每次都要跳过前 N 行）。流式查询更适合搭配“基于主键或时间戳的游标分页”：
立即学习“Java免费学习笔记（深入）”；
- 首次查询：
SELECT * FROM logs WHERE create_time > '2026-01-01' ORDER BY create_time LIMIT 10000 - 后续请求带上上一批最后一条的
create_time值继续查 - 这样每批都是索引扫描，无偏移计算开销
再配合流式 ResultSet，就能稳定维持低内存、低延迟的数据管道。
资源与连接生命周期要严格匹配
流式查询期间 ResultSet 会持续占用数据库连接和服务器端游标。一旦处理中断或未及时关闭，极易引发连接泄漏或服务端游标堆积：
- 务必用 try-with-resources 包裹
Statement和ResultSet - 不要在流式读取中途调用
rs.close()，应让 while 循环自然结束再释放 - 连接池需配置合理超时：
connection-timeout、leak-detection-threshold（如 HikariCP 中设为 60 秒） - Kylin 等 OLAP 引擎还建议开启
acceptPartial=true，允许返回部分结果防卡死
导出场景推荐组合方案
如果目标是导出 CSV 或 Excel，流式查询只是第一步。完整链路建议：
- 数据库层：流式 ResultSet 逐行读取
- 应用层：用
BufferedWriter写 CSV，或用 Apache POI 的 SXSSF（流式 Excel）写 .xlsx - 异步化：把“读 DB → 写文件”封装成独立线程或 CompletableFuture，避免阻塞 Web 请求线程
- 加进度反馈：每处理 10 万行更新一次状态，方便前端轮询或日志追踪
