mysql中fetchsize生效需同时满足三个硬性条件：连接参数usecursorfetch=true、statement类型为type_forward_only+concur_read_only、setfetchsize(integer.min_value)或调用enablestreamingresults()，缺一不可。
关键不在“设了没”，而在“怎么设才生效”。fetchSize 是 JDBC 中控制数据分批拉取的核心参数，但它在不同数据库驱动中行为差异极大——设错或忽略前提条件，等于白设。
MySQL 必须满足三个硬性条件才能让 fetchSize 生效
MySQL 驱动默认无视 fetchSize，无论你设成 10 还是 1000，结果集仍会一次性全量加载到内存。要真正启用流式读取，必须同时满足：
- 连接字符串中添加 useCursorFetch=true（5.0+ 驱动必需）
- Statement 创建时指定类型为 TYPE_FORWARD_ONLY 且并发模式为 CONCUR_READ_ONLY
- 调用 setFetchSize(Integer.MIN_VALUE) 或等效的 enableStreamingResults()
三者缺一不可。只设 fetchSize 而没开游标、没设游标类型，JVM 内存照样爆。
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
Oracle 和 PostgreSQL 对 fetchSize 更友好，但仍有细节陷阱
Oracle 默认 fetchSize 是 10，适合小查询；面对千万级表，建议设为 1000–5000，兼顾网络往返与单次内存占用。PostgreSQL 的 pgjdbc 驱动支持 fetchSize，但需注意：
- PreparedStatement 构造时必须显式传入 ResultSet.TYPE_FORWARD_ONLY
- 避免在事务中长时间持有 ResultSet，否则服务器端游标可能被回收或阻塞其他操作
- 实测中，fetchSize 设为 1000 时内存峰值比默认值下降约 60%，而设为 10000 后 GC 压力明显上升，收益递减
别只盯着 fetchSize，配套配置同样关键
单靠 fetchSize 无法根治 OOM，它只是流式读取的“开关”，不是万能缓存控制器：
- 关闭自动提交：大数据查询期间保持 connection.setAutoCommit(false)，避免隐式事务开销干扰游标生命周期
- 及时关闭资源：ResultSet、Statement、Connection 必须按顺序显式 close，尤其 ResultSet 不 close 会导致服务器端游标长期驻留
- 配合连接池调优：如 HikariCP 中设置 connection-timeout=30000、max-lifetime=3600000，防止长查询拖垮连接池
验证是否真正生效的两个简单方法
光看代码不等于跑通，必须现场验证：
- 启动 JVM 时加参数 -XX:+PrintGCDetails，观察 full gc 是否大幅减少；若仍频繁触发，说明数据仍在全量加载
- 在 while(rs.next()) 循环内加入计数器和日志，每处理 10000 行打印一次耗时与当前堆内存使用率（Runtime.getRuntime().freeMemory()），若内存曲线平稳上升而非陡增，说明流式生效
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
