preparedstatement.setfetchsize() 不直接降低内存占用，而是通过控制每次网络往返获取的行数（如50–500）来间接限制jvm堆内缓存的数据量，需配合type_forward_only、游标启用及避免随机访问方法才能生效。
PreparedStatement.setFetchSize() 本身不直接降低内存占用，但它能显著影响 JDBC 驱动从数据库拉取数据的“分批节奏”，从而间接控制 JVM 堆内缓存的数据量。关键在于：它告诉驱动“每次网络往返最多取多少行”，而不是把结果集一次性全载入内存。
fetchSize 的作用机制不是“限制内存”，而是“控制缓冲区大小”
多数主流 JDBC 驱动（如 PostgreSQL 的 pgjdbc、MySQL 的 Connector/J、Oracle 的 ojdbc）在启用流式读取或游标模式时，会将 setFetchSize(n) 解释为：
- 对服务器端声明一个“服务器游标”，并设置每次 fetch 最多返回 n 行；
- 客户端只保留当前这批（≤n 行）已解码的
ResultSet行对象在内存中； - 当调用
next()超出当前批次时，驱动自动发起下一次 fetch 请求——旧批次数据可被 GC 回收。
⚠️ 注意：若未配合禁用“全部加载”行为（如 MySQL 默认 useCursorFetch=true + fetchSize > 0），或未设置合适的 Statement 类型（需 TYPE_FORWARD_ONLY），setFetchSize() 可能被忽略。
必须搭配的配置项才能真正生效
仅调用 setFetchSize(100) 往往无效。需同步满足以下条件：
- 使用 TYPE_FORWARD_ONLY + CONCUR_READ_ONLY 的 Statement：这是游标式流读的前提；
-
连接 URL 中启用游标支持：例如 MySQL 加
?useCursorFetch=true，PostgreSQL 默认支持（但需setFetchSize > 0且非TYPE_SCROLL_SENSITIVE）； - 避免调用 ResultSet 的 getRow()、last()、absolute() 等需要随机访问的方法：它们会强制驱动缓存全部结果；
- 及时关闭 ResultSet 和 Statement：防止游标和服务端资源泄漏。
合理设置 fetchSize 的经验值与权衡
没有全局最优值，需按场景测试。常见建议：
- 50–500：适合大多数 OLAP 场景，平衡网络往返次数与单次内存峰值；
- 10–20：网络延迟高、单行数据极大（如含 BLOB）、GC 压力敏感时；
- 不建议设为 Integer.MAX_VALUE 或非常大值：等同于关闭流式，失去控制意义；
- 不要设为 1：网络开销剧增，吞吐骤降，得不偿失。
可通过 JVM 监控（如 VisualVM 观察老年代增长速率）+ 数据库侧游标状态（如 PostgreSQL 的 pg_cursors）验证是否真正启用了服务器端游标。
更彻底的内存控制：配合流式处理逻辑
即使 fetchSize 生效，若业务代码把每行数据长期 hold 在集合里（如 list.add(row)），内存仍会持续上涨。应做到：
- 逐行处理、即时转换、尽快释放引用；
- 用 try-with-resources 确保 ResultSet 关闭；
- 必要时用
ResultSet.unwrap(YourDriverStreamingClass.class)获取底层流式能力（如 pgjdbc 的PGCopyInputStream）； - 对超大数据导出，优先考虑数据库原生导出命令（
COPY TO、mysqldump --tab）而非 JDBC 拉取。
