MyBatis流式查询实战：大数据量查询防OOM的核心原理与安全实现

你有没有遇到过这样的场景：一个看似简单的数据导出功能，在测试环境跑得好好的，一到生产环境就突然内存飙升，直接 OOM（OutOfMemoryError）把服务干趴下？你查了半天日志，发现罪魁祸首只是一条平平无奇的SELECT * FROM large_table。

这不是段子，而是很多后端开发者踩过的真实大坑。当数据量从几千条变成几百万条时，传统的 JDBC 查询方式会瞬间将海量数据全部加载到 JVM 内存中，内存被“挤爆”几乎是必然结果。很多人第一反应是调大 JVM 堆内存，但这只是饮鸩止渴，数据再大一点呢？

今天要聊的MyBatis 流式查询，就是专门用来“拆弹”的。它不是什么高深的新技术，却是处理大数据量查询时，避免内存溢出的“标准答案”。很多人知道这个概念，但在实际项目中要么不敢用，要么用错了，反而引入了连接泄露的新问题。

本文将彻底讲清楚：为什么一行普通的查询代码能“挤爆”内存？MyBatis 流式查询的原理是什么？如何正确、安全地使用它？以及，在什么场景下你其实根本不需要它。

1. 这篇文章真正要解决的问题

我们首先得达成一个共识：技术方案的选择，永远是对“成本”的权衡。这里的成本包括内存成本、CPU成本、网络I/O成本，以及最重要的——开发和维护的复杂度成本。

核心问题：当你的 Java 应用需要从数据库查询并处理大量数据（比如百万级以上）时，如何避免一次性加载全部数据导致 JVM 内存溢出（OOM）？

传统方案的陷阱：

1. 简单查询：List<User> users = userMapper.selectList(queryWrapper);。数据量一大，users这个 List 会持有所有数据对象，瞬间吃满堆内存。
2. 分页查询：这是最容易被误解的方案。很多人觉得LIMIT offset, size分页就安全了。但如果你需要全量处理数据（比如导出、数据迁移、批量计算），分页查询意味着要对数据库进行N次查询（N = 总数据量 / 每页大小）。每次查询都有建立连接、执行SQL、网络传输的开销，对数据库是巨大的压力，性能极差。
3. 调大堆内存：-Xmx8g调到-Xmx16g。数据量是无限的，内存是有限的。这本质上是把风险后移，并且会导致 GC 停顿时间变长，影响服务稳定性。

流式查询的价值：它提供了一种“细水长流”的数据消费模式。数据库服务器端执行查询后，并不是一次性发送所有结果，而是像打开一个水龙头，让客户端（你的应用）可以一条一条地、或者一小批一小批地拉取数据。在这个过程中，在 JVM 内存中同时存在的数据量始终是可控的（通常只有几条或一个批次）。

所以，这篇文章要解决的，不是“流式查询是什么”的概念问题，而是：

• 为什么它会成为大数据量查询的救星？
• 在MyBatis框架下，如何正确地实现它？
• 使用它需要注意哪些坑（特别是资源泄露）？
• 除了流式查询，还有没有其他备选方案？

如果你正在开发数据导出、报表生成、ETL任务、大数据量同步等功能，或者你的服务经常因为数据查询而内存告警，那么这篇文章就是为你写的。

2. 基础概念与核心原理

在深入代码之前，我们必须理解几个关键概念，否则很容易误用。

2.1 传统查询 vs. 流式查询

我们可以用一个快递仓库的比喻来理解：

• 传统查询（一次性加载）：你想从仓库（数据库）取 10000 件商品（数据行）。仓库管理员（数据库驱动）的做法是，把这 10000 件商品全部打包，用一辆巨型卡车一次性运到你家门口（应用内存）。你的客厅（JVM堆）必须足够大才能放下所有包裹，否则就“爆仓”（OOM）了。
• 流式查询：同样是取 10000 件商品。现在，仓库管理员开通了一条传送带（数据库游标）。他每次只放 1 件或一小箱（Fetch Size）商品上传送带，运到你这里。你拿到一件，处理一件（或处理一小箱），然后告诉传送带“下一件”。你的门口始终只有少量商品，客厅永远宽敞。

这个“传送带”机制，在数据库层面依赖于游标（Cursor）。

2.2 数据库游标（Cursor）与 Fetch Size

• 游标：可以把它想象成数据库结果集的一个“指针”或“书签”。当执行一条查询语句时，数据库先在服务端准备好所有符合条件的结果，游标初始指向第一条记录之前的位置。
• Fetch Size（获取大小）：这是客户端（JDBC驱动）告诉数据库服务器的一个参数：“你每次给我发多少条数据？”。
  • 在传统模式下，JDBC驱动可能会设置一个很大的 Fetch Size，或者直接让数据库发送所有数据。
  • 在流式模式下，我们会设置一个较小的、合理的 Fetch Size（比如 100、500）。这意味着，尽管数据库服务端知道所有结果，但网络传输和客户端内存中，每次只流动一个“批次”的数据。

重要关系：流式查询的实现，本质是通过 JDBC 驱动，利用数据库的游标机制，并配合合理的Fetch Size来实现的。MyBatis 作为持久层框架，是对 JDBC 的封装，它提供了更便捷的方式来使用这个特性。

2.3 MyBatis 如何支持流式查询？

MyBatis 提供了两种主要方式来实现流式查询：

1. ResultHandler接口：这是一种“推送”模式。你实现一个处理器，MyBatis 会遍历结果集，每获取到一条记录，就“推送”给你的处理器回调一次。你可以在回调方法中处理这条数据，然后丢弃它。
2. Cursor<T>接口：这是一种“拉取”模式。查询返回一个Cursor对象，它实现了Iterator接口。你可以像遍历集合一样，用hasNext()和next()方法一条一条地“拉取”数据。这种方式更符合编程直觉，也是目前更推荐的方式。

两者的核心共同点：在遍历过程中，它们都不会将整个结果集一次性加载到一个List中。数据是“流式”地被消费掉的。

理解了这些原理，我们就能明白，流式查询节省的是JVM 堆内存，但它会长时间占用数据库连接和游标资源。这就是它最大的风险点，我们会在后面的“坑”里详细讲。

3. 环境准备与前置条件

在开始编写代码前，请确保你的环境满足以下要求。本文以最常见的 Spring Boot + MyBatis 组合为例。

1. 开发环境与工具：

• JDK：8 或以上版本（推荐 JDK 11+，本文示例基于 JDK 8 语法）。
• 构建工具：Maven 或 Gradle。
• IDE：IntelliJ IDEA, Eclipse, VS Code 等均可。

2. 项目依赖（Mavenpom.xml）：你需要引入 Spring Boot、MyBatis 以及数据库驱动。以下是一个基础的依赖配置：

<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.7.18</version> <!-- 请根据实际情况选择稳定版本 --> <relativePath/> </parent> <dependencies> <!-- Spring Boot Web (如果提供API) --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <!-- MyBatis Spring Boot Starter --> <dependency> <groupId>org.mybatis.spring.boot</groupId> <artifactId>mybatis-spring-boot-starter</artifactId> <version>2.3.0</version> <!-- 请匹配Spring Boot版本 --> </dependency> <!-- 数据库驱动 (以MySQL为例) --> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> <version>8.0.33</version> <!-- 建议使用8.x版本，支持更好的流式特性 --> </dependency> <!-- Lombok (可选，简化实体类) --> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> <!-- 测试 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> </dependency> </dependencies>

3. 数据库准备：你需要一个测试表来模拟大数据量。这里创建一个简单的用户表：

CREATE TABLE `large_user` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `name` varchar(255) DEFAULT NULL, `email` varchar(255) DEFAULT NULL, `age` int(11) DEFAULT NULL, `created_at` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 插入测试数据，这里可以用存储过程或程序批量插入，例如插入100万条。 -- 为了演示，我们先理解表结构即可。

4. MyBatis 配置（application.yml）：关键的配置在这里，它决定了 MyBatis 的默认行为。

spring: datasource: url: jdbc:mysql://localhost:3306/your_database?useSSL=false&serverTimezone=UTC&useUnicode=true&characterEncoding=utf8 username: your_username password: your_password driver-class-name: com.mysql.cj.jdbc.Driver # 对于流式查询，连接池的配置也很重要 hikari: maximum-pool-size: 10 # 连接池大小，根据实际情况调整 connection-timeout: 30000 idle-timeout: 600000 max-lifetime: 1800000 mybatis: configuration: # 非常重要！确保下划线转驼峰命名开启，方便映射 map-underscore-to-camel-case: true # 默认的 fetchSize，对某些驱动有影响。设为负数（默认）通常使用驱动默认值。 # 对于流式查询，我们通常在Mapper方法上通过注解单独设置。 # default-fetch-size: 100 # 指定mapper.xml文件位置 mapper-locations: classpath:mapper/*.xml

环境要点总结：

• MySQL 驱动 8.x对游标支持更好。
• 数据库连接池（如 HikariCP）是生产级应用的标配，流式查询会长时间占用连接，连接池配置需要合理。
• MyBatis 的default-fetch-size全局配置需谨慎，对于流式查询，更推荐在具体方法上通过注解控制。

4. 核心流程拆解：实现一个安全的流式查询

让我们一步步拆解，从实体类、Mapper 接口到服务层，如何构建一个完整且安全的流式查询流程。

4.1 第一步：定义实体类

对应数据库表large_user。

// 文件路径：src/main/java/com/example/demo/entity/User.java package com.example.demo.entity; import lombok.Data; import java.time.LocalDateTime; @Data public class User { private Long id; private String name; private String email; private Integer age; private LocalDateTime createdAt; }

4.2 第二步：创建 Mapper 接口与 XML

这是实现流式查询的核心。我们将演示两种方式：Cursor和ResultHandler。

方式一：使用Cursor<T>（推荐）

// 文件路径：src/main/java/com/example/demo/mapper/UserMapper.java package com.example.demo.mapper; import com.example.demo.entity.User; import org.apache.ibatis.annotations.Mapper; import org.apache.ibatis.annotations.Select; import org.apache.ibatis.cursor.Cursor; @Mapper public interface UserMapper { /** * 流式查询所有用户（使用Cursor） * @Select注解中通过`fetchSize`设置获取大小，Integer.MIN_VALUE是MySQL驱动的一个特殊值，会启用流式模式。 * 也可以设置为一个正数，如100。 */ @Select("SELECT id, name, email, age, created_at FROM large_user ORDER BY id") Cursor<User> selectAllUsersStreaming(); }

关键点解释：

• @Select：直接使用注解编写SQL，简洁明了。
• fetchSize = Integer.MIN_VALUE：这是一个针对 MySQL JDBC 驱动的“魔法值”。设置为此值会告诉驱动，我们希望以流式方式获取结果。对于其他数据库（如 PostgreSQL），可能需要设置一个正整数（如fetchSize = 100）。务必查阅你所使用数据库驱动的官方文档。
• 返回值Cursor<User>：这就是我们的“传送带”手柄。

方式二：使用ResultHandler（传统方式）

// 在同一个UserMapper接口中增加方法 /** * 流式查询所有用户（使用ResultHandler） * 注意：这个方法返回值为void，结果通过handler参数处理。 */ @Select("SELECT id, name, email, age, created_at FROM large_user ORDER BY id") void selectAllUsersWithHandler(ResultHandler<User> handler);

4.3 第三步：编写服务层逻辑

服务层负责获取Cursor并安全地遍历它，或者使用ResultHandler。

服务类（使用Cursor）：

// 文件路径：src/main/java/com/example/demo/service/UserService.java package com.example.demo.service; import com.example.demo.entity.User; import com.example.demo.mapper.UserMapper; import lombok.extern.slf4j.Slf4j; import org.apache.ibatis.cursor.Cursor; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.stereotype.Service; import org.springframework.transaction.annotation.Transactional; import java.util.ArrayList; import java.util.List; @Service @Slf4j public class UserService { @Autowired private UserMapper userMapper; /** * 使用Cursor进行流式查询并处理数据 * 关键：必须在事务内使用Cursor，并且确保finally块中关闭Cursor。 */ @Transactional(readOnly = true) // 只读事务，非常重要！ public void processUsersWithCursor() { Cursor<User> cursor = null; try { cursor = userMapper.selectAllUsersStreaming(); // 获取游标 int count = 0; List<User> batch = new ArrayList<>(1000); // 模拟批次处理 for (User user : cursor) { // 遍历Cursor，本质是迭代器 // 处理单条数据，例如：转换、校验、计算 // log.info("Processing user: {}", user.getName()); // 模拟批次处理：每1000条执行一次操作（如写入文件、发送消息） batch.add(user); if (batch.size() >= 1000) { processBatch(batch); batch.clear(); } count++; } // 处理最后一批 if (!batch.isEmpty()) { processBatch(batch); } log.info("Total users processed: {}", count); } catch (Exception e) { log.error("Error processing users with cursor", e); throw e; // 抛出异常让事务回滚 } finally { // 至关重要：显式关闭Cursor，释放数据库资源 if (cursor != null && !cursor.isClosed()) { cursor.close(); } } } private void processBatch(List<User> batch) { // 这里实现你的批次处理逻辑，例如： // 1. 写入CSV文件 // 2. 批量插入到另一个数据库 // 3. 发送到消息队列 // 4. 进行聚合计算 log.debug("Processing batch of size: {}", batch.size()); // 模拟处理耗时 // try { Thread.sleep(10); } catch (InterruptedException e) { ... } } }

代码逻辑拆解与要点：

1. @Transactional(readOnly = true)：这是使用Cursor时必须的！流式查询需要在同一个数据库连接和事务中完成遍历。如果不在事务中，MyBatis 在执行完 Mapper 方法后可能立即关闭连接，导致遍历时连接已关闭而报错。readOnly=true提示这是一个只读事务，对性能有一定优化。
2. try-catch-finally块：这是资源安全管理的标准模式。确保在任何情况下（正常结束或异常）都能关闭Cursor。
3. 遍历Cursor：for (User user : cursor)语法糖背后就是调用cursor.iterator()。每次next()都会从数据库游标中获取下一条（或下一批，取决于fetchSize）数据。
4. 批次处理：在循环内直接处理单条数据是可行的，但为了提升效率（比如减少I/O次数），我们通常会将数据累积到一个批次（如1000条）再进行一次处理（processBatch方法）。
5. 关闭资源：cursor.close()会关闭底层的 JDBCResultSet，释放数据库游标和相关的服务器端资源。忘记关闭是导致数据库连接泄露的常见原因！

服务类（使用ResultHandler）：

/** * 使用ResultHandler进行流式查询 */ @Transactional(readOnly = true) public void processUsersWithHandler() { userMapper.selectAllUsersWithHandler(new ResultHandler<User>() { private int count = 0; private List<User> batch = new ArrayList<>(1000); @Override public void handleResult(ResultContext<? extends User> resultContext) { User user = resultContext.getResultObject(); // 处理单条数据 batch.add(user); if (batch.size() >= 1000) { processBatch(batch); batch.clear(); } count++; // 可以通过resultContext.stop()提前终止 // if (count > 10000) { // resultContext.stop(); // } } // 可以重写handleResult的重载方法，但通常用这个就够了 }); // ResultHandler的方式由MyBatis自动管理资源，通常不需要手动关闭。 log.info("ResultHandler processing finished."); }

ResultHandler方式要点：

• 推送模式：MyBatis 控制循环，每得到一条数据就“推送”到你的handleResult方法。
• 资源管理：MyBatis 会在方法执行完毕后自动清理ResultSet和Statement，通常比Cursor方式更不易泄露资源。
• 灵活性：可以通过resultContext.stop()随时停止处理。
• 缺点：代码结构更分散，不如Cursor的迭代器模式直观；且难以在外部控制遍历过程。

4.4 第四步：创建控制器（可选）

如果你需要通过 HTTP API 触发这个流式处理，可以创建一个简单的控制器。

// 文件路径：src/main/java/com/example/demo/controller/UserController.java package com.example.demo.controller; import com.example.demo.service.UserService; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RestController; @RestController @RequestMapping("/api/users") public class UserController { @Autowired private UserService userService; @GetMapping("/export") public String exportUsers() { // 注意：对于HTTP请求，流式查询处理大量数据可能超时。 // 更常见的做法是触发一个异步任务（如使用@Async或消息队列）。 userService.processUsersWithCursor(); return "Data export started (streaming mode)."; } }

HTTP请求警告：在同步 HTTP 请求中处理超大数据流很容易导致请求超时。生产环境中，这类耗时操作应该改为异步任务，立即返回一个任务ID，客户端再通过轮询或 WebSocket 获取进度和结果。

5. 运行结果与效果验证

如何验证我们的流式查询真的在“流式”工作，而不是一次性加载？我们可以通过观察 JVM 内存使用情况来验证。

1. 准备测试数据：在large_user表中插入足够多的数据，比如 100 万条。可以使用简单的存储过程或编写一个 Java 程序批量插入。

2. 编写一个对比测试：创建一个传统的查询方法作为对比。

// 在UserService中添加 /** * 传统查询：一次性加载所有数据（危险！） */ @Transactional(readOnly = true) public List<User> getAllUsersTraditional() { // 假设我们有一个返回List的Mapper方法 // @Select("SELECT * FROM large_user") // List<User> selectAllUsers(); return userMapper.selectAllUsers(); // 这个方法需要你在Mapper中定义 } public void processUsersTraditional() { List<User> allUsers = getAllUsersTraditional(); // 一次性加载到内存！ log.info("Loaded {} users into memory.", allUsers.size()); // ... 处理数据 }

3. 观察内存变化：

• 传统方法：调用processUsersTraditional()。在启动应用时设置较小的堆内存（例如-Xmx256m）。当数据量超过内存容量时，你会看到控制台抛出java.lang.OutOfMemoryError: Java heap space异常，并且在抛出异常前，通过 JConsole 或 VisualVM 工具观察，会发现堆内存使用率瞬间飙升至接近 100%。
• 流式方法：调用processUsersWithCursor()。即使堆内存很小，服务也不会 OOM。内存使用曲线会呈现平稳的“锯齿状”——随着批次处理，会有小幅的上升和下降（由创建对象和GC引起），但峰值远低于总堆大小，永远不会持续增长到爆掉内存。

4. 验证数据库连接：流式查询会长时间占用一个数据库连接。你可以通过监控数据库的SHOW PROCESSLIST;命令（MySQL）来观察。在执行流式查询期间，你会看到对应连接的状态一直是Sending data或Writing to net，直到遍历结束或游标关闭。

成功标志：

• 程序能稳定处理远超内存容量的数据量。
• JVM 内存使用平稳，无持续增长。
• 数据处理完毕后，数据库连接被正确释放（回到连接池）。

6. 常见问题与排查思路

流式查询用起来并不复杂，但坑却不少。下面这个表格整理了最常见的问题和解决方法。

7. 最佳实践与工程建议

掌握了基础用法和避坑指南后，我们来看看如何将流式查询用得更加优雅和健壮。

7.1 使用 Try-With-Resources 自动关闭 Cursor（强烈推荐）

这是 Java 管理资源的标准方式，能确保在任何情况下资源都会被关闭。

@Transactional(readOnly = true) public void processUsersWithCursorSafely() { // try-with-resources 语法，Cursor实现了AutoCloseable接口 try (Cursor<User> cursor = userMapper.selectAllUsersStreaming()) { int count = 0; List<User> batch = new ArrayList<>(1000); for (User user : cursor) { batch.add(user); if (batch.size() >= 1000) { processBatch(batch); batch.clear(); // 清空列表，释放对已处理对象的引用 } count++; } processBatch(batch); // 处理最后一批 log.info("Processed {} users safely.", count); } catch (Exception e) { log.error("Stream processing failed", e); throw e; // 或进行其他错误处理 } // 无需手动调用 cursor.close()，try块结束后会自动调用。 }

7.2 为流式查询方法起一个明确的名字

在 Mapper 接口中，通过方法名清晰表达意图，提高代码可读性。

// 好名字 Cursor<User> streamAllUsers(); Cursor<User> findUsersForExport(Condition condition); // 不够好的名字 Cursor<User> selectAll(); // 看不出是流式 List<User> selectAllStreaming(); // 返回值是List，名字却叫Streaming，矛盾

7.3 将处理逻辑抽象成策略

将“如何处理每一条数据”的逻辑抽象出来，使流式查询的框架代码可以复用。

public interface StreamingProcessor<T> { /** * 处理单条数据 */ void processItem(T item); /** * 处理一个批次的数据（可选） */ default void processBatch(List<T> batch) { for (T item : batch) { processItem(item); } } /** * 所有数据处理完毕后的回调（可选） */ default void onFinish() {} } @Service public class GenericStreamingService { @Autowired private SqlSessionTemplate sqlSessionTemplate; // 用于获取Mapper @Transactional(readOnly = true) public <T> void processStreaming(String statementId, StreamingProcessor<T> processor, int batchSize) { // 通过SqlSession获取Cursor，更灵活 try (Cursor<T> cursor = sqlSessionTemplate.selectCursor(statementId)) { List<T> batch = new ArrayList<>(batchSize); for (T item : cursor) { processor.processItem(item); batch.add(item); if (batch.size() >= batchSize) { processor.processBatch(batch); batch.clear(); } } if (!batch.isEmpty()) { processor.processBatch(batch); } processor.onFinish(); } catch (Exception e) { // 处理异常 } } } // 使用示例 streamingService.processStreaming( "com.example.mapper.UserMapper.streamAllUsers", new StreamingProcessor<User>() { @Override public void processItem(User user) { // 你的业务逻辑 } }, 1000 );

7.4 异步与背压处理

对于超大数据量或处理较慢的场景，可以考虑异步流式处理，并引入背压（Backpressure）机制，防止生产者（数据库）速度远快于消费者（你的处理逻辑），导致内存中积压未处理的批次。

• 异步：使用@Async注解或CompletableFuture将流式处理任务提交到线程池执行，避免阻塞主线程或HTTP请求线程。
• 背压：在批次处理逻辑中，如果队列已满，则暂停从Cursor中拉取数据。这通常需要结合有界队列和信号量来实现，复杂度较高。一个简单的实践是调整fetchSize和处理批次大小，让消费速度能跟上生产速度。

7.5 监控与告警

在生产环境使用流式查询，必须做好监控：

1. 数据库连接池监控：关注活跃连接数、等待连接数。流式查询长时间占用连接是正常现象，但数量异常增长可能意味着泄露。
2. 应用内存监控：观察老年代内存和GC情况，确保没有因处理逻辑不当导致的内存缓慢增长。
3. 查询超时监控：为流式查询设置合理的超时时间（可以在数据库连接字符串或MyBatis配置中设置socketTimeout），避免一个慢查询永远不释放连接。

7.6 明确使用边界：什么时候不该用流式查询？

流式查询不是银弹，以下场景请慎重或避免使用：

• 数据量很小（几千条以内）：传统方式更简单，性能开销更小。
• 需要多次随机访问结果集数据：流式查询是单向的，只能向前遍历，不能回头或跳转。
• 网络环境极差：频繁的网络I/O（如果fetchSize很小）会放大延迟影响。
• 事务隔离级别要求高，且处理时间极长：长事务会持有锁，可能阻塞其他操作。对于 MySQL，流式查询默认在REPEATABLE READ隔离级别下，会使用一致性读视图，可能对性能有影响。

8. 总结与后续学习方向

通过本文，我们深入剖析了 MyBatis 流式查询如何成为应对大数据量查询、防止内存 OOM 的利器。核心要点再回顾一下：

1. 知其所以然：流式查询的核心原理是利用数据库游标和fetchSize，实现数据的“按需加载，即时消费”，从而将内存占用从O(N)降低到O(1)或O(BatchSize)。
2. 正确使用：在 MyBatis 中，优先使用Cursor<T>接口，并务必将其置于@Transactional事务内，使用try-with-resources语法确保资源关闭。
3. 规避风险：最大的风险是数据库连接泄露和长事务。务必关闭Cursor，合理设置连接池和超时，并优化数据处理速度。
4. 最佳实践：抽象处理逻辑、合理设置批次大小、做好监控、明确适用场景。

流式查询解决了“内存放不下”的问题，但它把压力转移到了“数据库连接占用时间”和“网络I/O次数”上。这是一个典型的权衡。

后续你可以深入探索的方向：

• 数据库方言差异：不同数据库（PostgreSQL, Oracle, SQL Server）对游标和流式查询的支持方式、fetchSize的语义可能不同，需要查阅对应驱动的文档。
• 与 Spring Data JPA 的结合：如果你使用 JPA，可以研究如何通过ScrollableResults或 Hibernate 的StatelessSession实现类似功能。
• 响应式编程集成：在 Spring WebFlux 项目中，可以将Cursor转换为Flux，实现真正的响应式数据流处理。
• 更复杂的数据管道：结合 Apache Spark、Flink 或简单的 Spring Batch，将流式查询作为数据源，构建更强大的批处理或流处理任务。

处理海量数据是现代后端开发的必修课。流式查询是工具箱中一件关键且实用的武器。理解其原理，掌握其正确用法，警惕其陷阱，你就能在“数据洪流”面前，从容地打开那道安全阀，让数据平稳、高效地流过你的系统。