java jdbc流式查询核心是边拉边用、禁用全量缓存、启用服务端游标并手动管理资源；需配置usecursorfetch=true、defaultfetchsize、type_forward_only与fetchsize=min_value，并逐行遍历、及时关闭资源。

Java JDBC 处理超大数据量流式查询，核心是让数据“边拉边用”，不囤积在 JVM 堆里。关键不在加内存，而在控制数据加载方式——禁用默认全量缓存、启用服务端游标、手动管理连接与结果集生命周期。

必须配置的 JDBC 连接参数

MySQL 驱动默认会把整个结果集一次性读进客户端内存，必须显式关闭该行为：

• URL 中添加 useCursorFetch=true：启用服务端游标支持（否则 fetchSize 无效）
• 设置 defaultFetchSize=1000（或按需调整为 500–2000），配合后续代码生效
• 连接串建议带上 zeroDateTimeBehavior=convertToNull&useSSL=false&serverTimezone=UTC，避免时区和空时间干扰

执行查询时的关键代码写法

不能用普通 executeQuery()，要主动声明游标语义：

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• 创建 Statement 时指定类型：createStatement(ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY)
• 设置 fetchSize 为 Integer.MIN_VALUE（即 -2147483648），这是 JDBC 驱动识别“流式模式”的信号
• 务必在 finally 或 try-with-resources 中调用 rs.close()、stmt.close()、conn.close()，否则连接和游标长期占用，数据库会撑不住

流式处理过程中的注意事项

流式不是万能银弹，用错场景反而更危险：

• ResultSet 必须逐行遍历完才能发下一条 SQL，中途不能混用其他查询，否则抛 SQLException
• 不要对 rs 做 rs.last()、rs.getRow() 等随机访问操作，它只支持单向 forward-only
• 避免在循环内新建大对象（如 new ByteArrayOutputStream()），防止隐式副本导致内存翻倍；优先用 inputStream.transferTo(outputStream) 或直接写文件
• 若需分块聚合（如每 1 万条统计一次），在 for 循环中用计数器 + 条件 flush，别等全部读完再算

怎么验证真的流式了？

光改代码不够，得看效果：

• 用 jconsole 或 VisualVM 观察堆内存曲线：流式下应平稳低幅波动，而非陡升后卡住
• 查 MySQL 的 SHOW PROCESSLIST，能看到状态为 Sending data 并持续较长时间，说明服务端正在边生成边传输
• 对比耗时：流式首次响应快（几毫秒出第一条），但总耗时可能略长于全量加载——这是用时间换空间的合理代价

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南