如何通过PreparedStatement的setFetchSize()方法降低处理大量数据集时的内存消耗？

本文共计835个文字，预计阅读时间需要4分钟。

准备阶段

在创新过程中，准备阶段至关重要。这一阶段主要包括以下内容：

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 拉取。