在实际 Java 后端开发中，处理海量数据查询是一个绕不开的挑战。很多开发者习惯性地使用 List<T> 来接收数据库查询结果，这在数据量不大时没有问题。然而，当业务要求一次性导出几十万甚至上百万条记录时，这种“全量加载到内存”的方式会瞬间成为性能瓶颈，轻则导致长时间 GC 停顿，重则直接引发 OutOfMemoryError ，也就是我们常说的 OOM。这种问题在报表生成、数据同步、历史数据迁移等场景下尤为常见。

MyBatis 作为 Java 生态中广泛使用的持久层框架，除了提供便捷的 CRUD 映射，也内置了应对大数据量查询的解决方案——流式查询。流式查询的核心思想是“边读边处理”，它并非一次性将所有结果集加载到 JVM 内存中，而是通过数据库驱动和框架的配合，以“流”的形式逐条或分批将数据传递给应用程序进行处理，从而将内存占用控制在极低的水平。理解并正确使用 MyBatis 的流式查询，是避免因数据查询导致内存挤爆的关键技能。本文将深入探讨 MyBatis 流式查询的原理、两种核心实现方式（ Cursor 接口与 ResultHandler 接口），并通过对比分析，帮助你根据实际场景做出合适的技术选型。

1. 为什么“一行代码”就能挤爆内存？

在深入流式查询之前，我们必须先理解传统查询方式的内存风险究竟从何而来。这并非 MyBatis 的缺陷，而是由 JDBC 和常见编程模式共同决定的。

1.1 传统查询的内存加载过程

当你执行一个典型的 MyBatis 查询，例如 List<User> userList = userMapper.selectAll(); ，其背后的流程大致如下：

  1. 应用层调用 ：MyBatis 执行器接收到查询请求。
  2. JDBC 执行 ：通过 PreparedStatement 执行 SQL，获取 ResultSet 。
  3. 结果集全量加载 ：默认情况下，JDBC 驱动会将 ResultSet 中的所有数据一次性从数据库服务器通过网络传输到客户端（即你的应用服务器），并缓存在驱动层的内存中。
  4. ORM 映射 ：MyBatis 遍历这个已缓存在本地的 ResultSet ，为每一行数据创建实体对象（如 User 对象），并填充属性。
  5. 集合封装 ：所有创建好的对象被添加到一个 ArrayList 中。
  6. 返回结果 ：这个包含了所有数据的 List 被返回给调用者。

问题就出在第 3 步和第 5 步。假设一条记录映射为对象后占用 1KB 内存，查询 100 万条记录，仅对象本身就需要约 1GB 的堆内存。这还不包括 ArrayList 内部数组的开销、字符串常量池的占用等。对于大多数配置为 2GB 或 4GB 堆内存的 JVM 来说，这样一次查询就足以触发 Full GC，甚至直接导致 OOM。

1.2 OOM 的典型现象与排查

当发生因大数据查询导致的 OOM 时，通常会看到如下错误信息： 

java.lang.OutOfMemoryError: Java heap space

或者更具体的，在 GC 日志中观察到老年代被迅速填满。

使用 IntelliJ IDEA 或 Eclipse MAT 分析导出的 heap dump 文件（.hprof 文件），往往会发现某个 ArrayList 或 HashMap 对象占据了绝大部分内存，其内部元素就是你的业务实体对象。这就是“一行代码挤爆内存”的直观证据——那行调用 selectAll() 或类似方法的代码。

注意：排查 OOM 时，如果 .hprof 文件过大导致 IDE 无法打开，可以尝试使用命令行工具 jhat （JDK 自带）或功能更强的独立工具如 MAT 的独立版本进行分析。

1.3 流式查询如何解决内存问题

流式查询改变了上述流程的第 3 步。它通过配置，让 JDBC 驱动以“流”的方式处理 ResultSet 。在这种模式下：

  • 数据库端 ：保持游标（Cursor）打开，并等待客户端请求数据。
  • 驱动端 ：不再缓存全部结果，而是每次只从网络连接中读取有限条记录（例如一次一行）。
  • 应用端 ：MyBatis 映射完一条数据后，立即通过回调接口（ ResultHandler ）或迭代器（ Cursor ）将对象交给业务逻辑处理。处理完后，该对象理论上就可以被垃圾回收（如果未被其他引用持有），内存得以释放。

这样，无论总数据量是 1 万条还是 1000 万条，在应用服务器中同时存在于内存中的活动对象始终只有很少的一部分，内存压力得以根本性缓解。

2. 环境准备与依赖配置

在开始编写流式查询代码之前，需要确保你的项目环境正确配置。不同的数据库和 MyBatis 版本对流式查询的支持略有差异。

2.1 项目与依赖要求

首先，你需要一个基于 Maven 或 Gradle 的 Java 项目。本文以 Maven 为例，核心依赖如下：

1. MyBatis 依赖 ：必须使用 MyBatis 3.4.1 及以上版本，以获得对 Cursor 接口的稳定支持。建议使用较新版本。 

<dependency>
    <groupId>org.mybatis</groupId>
    <artifactId>mybatis</artifactId>
    <version>3.5.10</version> <!-- 示例版本，请使用最新稳定版 -->
</dependency>

2. 数据库驱动 ：以 MySQL 为例，需要确保驱动版本支持流式读取。较新的版本通常都支持。 

<dependency>
    <groupId>mysql</groupId>
    <artifactId>mysql-connector-java</artifactId>
    <version>8.0.33</version> <!-- 示例版本 -->
    <!-- 注意：对于 MySQL，使用 `com.mysql.cj.jdbc.Driver` -->
</dependency>

3. Spring Boot 集成（可选） ：如果你使用 Spring Boot，可以通过 mybatis-spring-boot-starter 简化配置。 

<dependency>
    <groupId>org.mybatis.spring.boot</groupId>
    <artifactId>mybatis-spring-boot-starter</artifactId>
    <version>2.3.0</version> <!-- 示例版本 -->
</dependency>

2.2 数据库连接配置关键参数

流式查询能否生效，严重依赖于 JDBC 连接的配置。必须在数据源配置中显式开启相关参数。

对于 MySQL： 在 application.yml 或 application.properties 中配置数据源时，需要添加关键的连接参数。 

spring:
  datasource:
    url: jdbc:mysql://localhost:3306/your_database?useSSL=false&serverTimezone=UTC&useCursorFetch=true&defaultFetchSize=100
    username: root
    password: your_password
    driver-class-name: com.mysql.cj.jdbc.Driver

关键参数解释：

  • useCursorFetch=true ：这是启用 MySQL 流式查询（服务端游标）的关键参数。它告诉 MySQL 驱动使用 Cursor 方式逐条获取数据，而不是默认的将全部结果加载到客户端内存。
  • defaultFetchSize=100 ：设置默认的抓取大小。这个值不是一次传输的数据量上限，而是一个提示值。设置为一个正整数（如 100, 1000）会促使驱动使用流式模式。 注意 ：如果设置为 Integer.MIN_VALUE ，驱动会尝试以最逐行的方式流式传输，但具体行为因驱动版本而异。对于 MySQL，通常设置一个正整数值即可。

对于 PostgreSQL： 

spring:
  datasource:
    url: jdbc:postgresql://localhost:5432/your_database?defaultRowFetchSize=100
    username: postgres
    password: your_password

PostgreSQL 驱动通常根据 fetchSize 参数决定是否使用流式查询。在代码中通过 Statement.setFetchSize(50) 设置，或在连接 URL 中通过 defaultRowFetchSize 设置。

警告：不正确的连接参数是导致流式查询失效的最常见原因。务必根据数据库类型查阅官方驱动文档，确认正确的参数名和值。

2.3 示例数据模型与 Mapper

为了后续演示，我们定义一个简单的数据模型和 Mapper 接口。

实体类 User.java ： 

public class User {
    private Long id;
    private String name;
    private String email;
    private LocalDateTime createTime;
    // 省略构造函数、getter、setter和toString方法
}

Mapper 接口 UserMapper.java ： 

@Mapper // 如果使用MyBatis-Spring集成
public interface UserMapper {
    // 传统查询方法 - 可能导致OOM
    List<User> selectAllUsers();

    // 方法1：返回Cursor的流式查询
    Cursor<User> selectAllUsersStreamByCursor();

    // 方法2：使用ResultHandler的流式查询
    void selectAllUsersStreamByHandler(ResultHandler<User> handler);
}

对应的 XML 映射文件 UserMapper.xml ： 

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd">
<mapper namespace="com.example.mapper.UserMapper">

    <select id="selectAllUsers" resultType="User">
        SELECT id, name, email, create_time as createTime
        FROM user
        <!-- 可能还有查询条件 -->
    </select>

    <!-- 流式查询Cursor方式：resultType不变，但MyBatis会特殊处理 -->
    <select id="selectAllUsersStreamByCursor" resultType="User">
        SELECT id, name, email, create_time as createTime
        FROM user
    </select>

    <!-- 流式查询ResultHandler方式：不需要resultType，通过parameterType指定处理器 -->
    <select id="selectAllUsersStreamByHandler" resultType="User" fetchSize="100">
        SELECT id, name, email, create_time as createTime
        FROM user
    </select>

</mapper>

注意第二个和第三个查询在 SQL 层面看起来完全一样，区别在于 Mapper 接口的返回类型和 XML 中的细微提示（如 fetchSize ，虽然它通常在驱动层配置更有效）。

3. 实现方式一：使用 Cursor 接口

Cursor 接口是 MyBatis 3.4.1 引入的用于流式查询的官方方式。它实现了 Iterable 和 Iterator 接口，允许你以类似迭代集合的方式遍历海量结果，而无需一次性加载所有数据。

3.1 Cursor 的基本用法

首先，在 Mapper 接口中定义返回 Cursor<T> 的方法。 

Cursor<User> selectAllUsersStreamByCursor();

对应的 XML 映射语句不需要特殊标签，使用普通的 <select> 即可，但确保 SQL 是正确的。

在 Service 或 Controller 层，你需要在一个 数据库事务 中打开并使用这个 Cursor 。这是因为流式查询依赖于一个打开的数据库连接和事务来保持游标有效。 

@Service
public class UserService {

    @Autowired
    private UserMapper userMapper;

    @Transactional // 关键：必须在一个事务内操作Cursor
    public void processUsersWithCursor() {
        try (Cursor<User> cursor = userMapper.selectAllUsersStreamByCursor()) {
            for (User user : cursor) { // 遍历Cursor
                // 处理每一条用户数据
                processSingleUser(user);
                // 对象user在此次循环后，如果没有被外部引用，就可以被GC回收
            }
        } catch (IOException e) {
            // Cursor实现了Closeable，关闭时可能抛出IOException
            throw new RuntimeException("Error processing cursor", e);
        }
        // 事务结束后，连接关闭，游标也会被释放
    }

    private void processSingleUser(User user) {
        // 模拟处理逻辑：例如写入文件、发送消息、计算统计值等
        System.out.println("Processing user: " + user.getName());
        // 这里不要将user对象添加到外部的List中，否则会失去流式意义！
    }
}

3.2 关键机制与原理

  1. 事务边界 ： @Transactional 注解至关重要。流式查询执行时，MyBatis 会从连接池获取一个连接并执行查询。 Cursor 对象本身持有这个连接和对应的 ResultSet 。如果不在事务中，方法执行完毕后，MyBatis 可能会立即关闭连接，导致 Cursor 无法读取后续数据，甚至报错。事务保证了在整个遍历过程中，连接始终有效。
  2. 资源管理 ： Cursor 实现了 Closeable 接口，因此使用 try-with-resources 语法是推荐做法。这能确保即使在遍历过程中发生异常，数据库游标和连接也能被正确关闭，避免资源泄漏。
  3. 遍历过程 ： for (User user : cursor) 这行代码每次迭代时，MyBatis 会通过 JDBC 驱动从数据库网络流中读取下一行（或下一批，取决于 fetchSize ）数据，将其映射为 User 对象，然后返回。之前的 User 对象如果没有被强引用，就会成为垃圾，等待回收。

3.3 使用 Cursor 的优缺点分析

优点：

  • 代码简洁 ：使用方式与迭代普通集合 ( List ) 高度相似，学习成本低。
  • 类型安全 ：返回的是泛型 Cursor<User> ，编译器能进行类型检查。
  • 易于集成 ：可以方便地与 Java 8 Stream API 结合（通过 StreamSupport ）。

缺点与注意事项：

  • 强事务依赖 ：必须在事务内使用，这限制了其应用场景（例如，在非事务性的定时任务或异步处理中需要额外设计）。
  • 连接占用时间长 ：遍历百万级数据可能耗时很长，这意味着一个数据库连接将被长时间占用，可能影响连接池性能。需要评估对连接池 max-active 等参数的影响。
  • 无法在 Mapper 层直接复用 ： Cursor 作为返回值，意味着数据处理逻辑（遍历和消费）必须紧跟在查询调用之后，无法将 Cursor 传递给其他层进行灵活处理。

4. 实现方式二：使用 ResultHandler 接口

ResultHandler 是一个回调接口，它允许你在 MyBatis 映射每一行结果时立即对其进行处理。这是 MyBatis 更早期、也更底层的流式查询支持方式。

4.1 ResultHandler 的基本用法

首先，定义一个实现 ResultHandler<T> 接口的类。通常我们使用匿名内部类或 Lambda 表达式。

Mapper 接口定义： 

void selectAllUsersStreamByHandler(ResultHandler<User> handler);

注意，方法返回类型是 void ，结果通过回调接口传递。

XML 映射文件： 与普通查询一样，但可以显式设置 fetchSize （尽管驱动配置优先级更高）。 

<select id="selectAllUsersStreamByHandler" resultType="User" fetchSize="250">
    SELECT id, name, email, create_time as createTime FROM user
</select>

在 Service 层调用： 

@Service
public class UserService {

    @Autowired
    private UserMapper userMapper;

    public void processUsersWithHandler() {
        // 不需要@Transactional注解，但查询执行过程本身仍在一个数据库会话中
        userMapper.selectAllUsersStreamByHandler(new ResultHandler<User>() {
            @Override
            public void handleResult(ResultContext<? extends User> resultContext) {
                User user = resultContext.getResultObject();
                // 处理单条数据
                processSingleUser(user);

                // 可以通过resultContext控制是否继续处理
                int count = resultContext.getResultCount();
                if (count >= 10000) {
                    // 例如，处理满10000条后主动停止
                    // resultContext.stop();
                }
            }
        });
        // 方法执行完毕，连接会自动关闭
    }

    // Java 8+ 可以使用Lambda表达式更简洁
    public void processUsersWithHandlerLambda() {
        userMapper.selectAllUsersStreamByHandler(resultContext -> {
            User user = resultContext.getResultObject();
            processSingleUser(user);
        });
    }

    private void processSingleUser(User user) {
        System.out.println("Processing user: " + user.getName());
    }
}

4.2 关键机制与原理

  1. 回调模式 ：MyBatis 在执行查询后，不会将结果收集到列表，而是为结果集的每一行调用一次 handleResult 方法。你在这个方法里拿到映射好的对象并立即处理。
  2. 连接管理 ：与 Cursor 不同，使用 ResultHandler 时，MyBatis 会在 selectAllUsersStreamByHandler 方法调用期间持有数据库连接，并在方法返回前关闭连接。因此，你通常不需要（也不应该）为这个方法添加 @Transactional ，除非它被嵌套在另一个需要事务的方法中。
  3. 流程控制 ： ResultContext 对象提供了 getResultCount() （当前已处理的行数）和 stop() 方法。你可以在处理一定数量数据后主动停止，这在处理到满足条件的数据后提前退出时非常有用。
  4. 线程模型 ： handleResult 方法是在执行查询的同一个线程中同步调用的。这意味着处理逻辑会阻塞数据库查询的推进。如果处理逻辑非常耗时，整体执行时间会变长。

4.3 使用 ResultHandler 的优缺点分析

优点：

  • 无事务约束 ：不需要强制开启事务，使用更灵活。
  • 连接占用可控 ：连接在 Mapper 方法执行完毕后立即释放，占用时间相对较短。
  • 可控制流程 ：可以通过 ResultContext.stop() 提前终止处理。
  • 适用于复杂处理 ：可以将处理逻辑封装在独立的 ResultHandler 实现类中，实现更好的职责分离。

缺点与注意事项：

  • 代码侵入性稍强 ：需要编写回调类或 Lambda，代码结构与传统方式差异较大。
  • 异常处理 ：如果 handleResult 方法中抛出异常，整个查询和处理过程会中断，需要做好异常捕获和处理。
  • 无法直接返回结果 ：由于是回调模式，处理结果无法像普通方法一样通过返回值传递。通常需要在外围准备一个收集器（如写入文件、更新统计变量等）。

5. Cursor 与 ResultHandler 的对比与选型

理解了两种方式的原理后，我们可以从多个维度进行对比，以便在实际项目中做出正确选择。

特性维度 Cursor<T> 接口 ResultHandler<T> 接口
代码风格 声明式，类似迭代集合，更直观。 命令式，回调模式，逻辑分散。
事务要求 必须 在事务内使用。 通常不需要事务，由 MyBatis 管理连接会话。
连接占用 连接在整个遍历期间被占用，时长与数据量和处理速度正相关。 连接仅在 Mapper 方法执行期间被占用，相对较短。
资源管理 需使用 try-with-resources 或手动关闭，否则可能导致连接泄漏。 由 MyBatis 自动管理连接关闭。
流程控制 可通过 break 终止循环，控制力在消费者。 可通过 ResultContext.stop() 终止，控制力在处理器内部。
结果传递 返回 Cursor 对象，可在方法间传递（但受事务限制）。 无返回值，结果通过回调即时消费，难以传递。
与 Stream API 集成 容易集成（ StreamSupport.stream(cursor.spliterator(), false) ）。 较难直接集成，需要自行适配。
适用场景 需要在事务上下文中进行复杂遍历，或希望以集合风格处理数据流。 简单的逐行处理、数据导出、转换，且不希望引入事务开销。
性能影响 长时间占用连接，对连接池压力大。处理逻辑慢会拖慢整体。 连接释放快。处理逻辑慢同样会拖慢整体，但连接压力小。

选型建议：

  1. 优先考虑 ResultHandler ：如果你的场景只是简单的读取-处理（如导出 CSV、数据清洗、发送消息），并且处理逻辑可以写在一个地方， ResultHandler 是更轻量、约束更少的选择。它避免了事务的复杂性，连接管理也更简单。
  2. 当需要事务或灵活遍历时选择 Cursor ：如果你的流式处理必须与其他数据库操作（如更新状态）在同一个事务中完成，或者你希望将数据流传递给更上层的逻辑进行灵活控制（例如，结合业务规则进行过滤和分发），那么 Cursor 是更好的选择。特别是与 Spring 的 @Transactional 和 Java Stream API 结合时，能写出非常清晰的代码。
  3. 混合使用 ：在某些复杂场景下，也可以考虑混合使用。例如，在一个事务方法内使用 Cursor 获取数据流，然后对每条数据调用一个使用 ResultHandler 的 Mapper 方法进行子查询（但这需要仔细设计以避免 N+1 查询问题）。

6. 生产环境实践与常见问题排查

将流式查询应用于生产环境，除了正确使用 API，还需要关注稳定性、性能和监控。

6.1 配置清单与检查项

在应用上线前，请对照此清单进行检查：

检查项 说明 推荐做法
数据库连接参数 确保已正确启用流式模式。 MySQL: useCursorFetch=true&defaultFetchSize=100 PostgreSQL: 在代码或URL中设置 fetchSize
MyBatis 版本 确保版本支持流式查询。 >= 3.4.1
数据库驱动版本 旧版本驱动可能不支持或存在 Bug。 使用较新的稳定版驱动。
事务管理（仅Cursor） 使用 Cursor 必须开启事务。 在方法上添加 @Transactional 。
资源关闭 必须关闭 Cursor ，防止连接泄漏。 使用 try-with-resources 语句。
超时设置 流式查询可能执行很久，需调整超时。 调整 spring.datasource.hikari.connection-timeout 或事务超时 @Transactional(timeout=3600) 。
连接池配置 长时间运行的流式查询会占用连接。 适当增大连接池 maximumPoolSize ，并监控连接使用情况。
JVM 内存监控 验证流式查询是否真的降低了内存占用。 通过 JConsole、VisualVM 或 APM 工具观察 Old Gen 内存增长曲线。

6.2 常见问题与排查路径

即使配置正确，在实际运行中也可能遇到问题。以下是典型的问题现象、原因及解决方案。

问题现象 可能原因 排查步骤 解决方案
流式查询没有生效，内存依然飙升 1. 数据库连接参数未正确配置。
2. fetchSize 设置不正确（如设为0或负值）。
3. 数据库驱动不支持或存在 Bug。 		1. 检查应用日志中打印的 JDBC URL。
2. 在数据库监控中观察网络流量，流式查询应是平稳持续流量，而非瞬间高峰。
3. 使用 JProfiler 等工具查看 ArrayList 或 HashMap 是否仍持有大量对象。 		1. 确认并修正连接参数。
2. 将 fetchSize 设置为一个正整数值（如 100-1000）。
3. 升级数据库驱动到最新稳定版。
使用 Cursor 时报 Connection is closed 或游标错误 1. 未在事务中使用 Cursor 。
2. 事务提前结束（如被标记为 rollback-only）。
3. 遍历 Cursor 的代码不在 @Transactional 方法调用链中。 		1. 检查方法是否添加了 @Transactional 。
2. 检查事务传播行为，确保流式查询在一个有效事务内执行。
3. 查看日志中是否有异常导致事务回滚。 		1. 为使用 Cursor 的方法添加 @Transactional 。
2. 确保事务方法内没有抛出未捕获的异常。
3. 考虑将遍历逻辑内嵌在事务方法中。
流式查询速度非常慢 1. 网络延迟高。
2. 处理单条数据的逻辑 ( processSingleUser ) 太耗时，阻塞了数据拉取。
3. 数据库服务器端排序或过滤开销大。 		1. 监控数据库服务器和应用的 CPU、网络 IO。
2. 分析 processSingleUser 方法的性能。
3. 检查 SQL 语句是否有优化的空间（如索引）。 		1. 优化处理逻辑，考虑异步或批量处理。
2. 对 SQL 查询条件建立索引。
3. 如果业务允许，在数据库端进行一些预处理。
内存泄漏，即使使用流式查询内存仍缓慢增长 1. 在 ResultHandler.handleResult 或 Cursor 迭代中，将对象添加到了外部的全局集合中。
2. 第三方库（如某些 JSON 序列化工具、缓存框架）无意中持有了对象引用。 		1. 审查代码，确保没有在流式处理中积累数据。
2. 使用内存分析工具查看堆积对象的 GC Root 路径。 		1. 修正代码，确保处理完的对象及时解除引用。
2. 检查并配置第三方库，避免不必要的对象缓存。
数据库连接池被耗尽 多个流式查询并发执行，每个都长时间占用一个连接。 监控连接池活跃连接数，看是否持续接近最大值。 1. 增加连接池最大连接数（是缓解，非根治）。
2. 优化 ：限制流式查询的并发度，或使用 ResultHandler 缩短连接占用时间。
3. 优化查询和处-理逻辑，减少单次查询耗时。

6.3 性能优化建议

  1. 合理设置 fetchSize ：这个值不是越大越好。值太小会增加网络往返次数；值太大则失去了流式的意义，可能一次加载过多数据到驱动层内存。通常建议从 100 到 1000 开始测试，根据网络延迟和处理速度找到一个平衡点。
  2. 优化单条处理逻辑 ：流式查询的整体速度受限于最慢的环节。如果 processSingleUser 方法中有 IO 操作（如写文件、调用外部 API），考虑引入批量写入或异步处理来提高吞吐量。
  3. 使用索引 ：确保流式查询的 SQL 语句使用了合适的索引，避免全表扫描。即使内存问题解决了，一个慢查询仍然会占用数据库资源很久。
  4. 监控与告警 ：对应用进行监控，关注长时间运行的数据库查询、连接池使用率、JVM 内存变化等指标。设置合理的告警阈值。
  5. 考虑分页的替代方案 ：对于某些超大数据集，如果业务允许，有时采用“分段分页”（根据自增ID或时间范围分段查询）比单一流式查询更可控，对数据库更友好。

流式查询是 MyBatis 提供的一个强大工具，能有效解决大数据量查询时的内存瓶颈。 Cursor 和 ResultHandler 两种方式各有适用场景，核心在于理解其背后“边读边处理”的原理以及对数据库连接和事务的管理差异。正确配置数据库连接参数是生效的前提，而将其应用于生产环境时，则需要综合考虑事务、连接池、超时、监控和异常处理。避免 OOM 只是第一步，构建一个稳定、高效的数据处理管道，才是架构能力的体现。在下一篇中，我们将探讨更复杂的场景，例如在流式查询中嵌套其他数据库操作、与 Spring Batch 等批处理框架集成，以及如何对流式查询进行单元测试。

Logo
亚马逊云科技技术品牌专区

更多推荐

open-code-review Codex 插件教程：对话式调用评审技能指南

本文是一份面向新手的 **open-code-review Codex 插件教程**，教你在 Codex 中通过对话式方式调用 open-code-review 的 AI 代码评审技能。open-code-review 是阿里巴巴开源的 AI 代码评审工具，采用"确定性流水线 + LLM Agent"混合架构，内置多语言评审规则（NPE、线程安全、XSS、SQL 注入等），可在 Codex 里用一

avatar 亚马逊云科技技术品牌专区

OBS Studio 完整指南：免费开源录屏与直播软件从零上手

想做一场像模像样的直播，或者把屏幕内容录成教程视频，但一想到商用软件的订阅费就有些犹豫？其实你不需要花一分钱。OBS Studio 是一款免费开源的直播与录屏软件，支持 Windows、macOS 和 Linux，采集、混音、编码、推流、录制，一条流水线全包了。## 先搞清楚 OBS Studio 是什么OBS Studio 是一个"场景化"的采集合成工具：你把摄像头、窗口、浏览器、图片、

avatar 亚马逊云科技技术品牌专区

如何用MediaCrawler爬取小红书抖音数据？7大平台爬虫从安装到实战完整指南

MediaCrawler 是一个支持小红书、抖音、快手、B站、微博、百度贴吧、知乎的开源自媒体数据采集工具。它能按关键词、按帖子、按创作者主页三种方式抓取笔记/视频内容、评论甚至二级评论，并把结果存成 JSON、CSV、Excel 或数据库。适合做市场调研、竞品监控、内容选题的运营人员，以及想要现成爬虫框架而不想从零写 JS 逆向的开发者。## 从一次"手动抄数据"说起想象这个场景：你负责

avatar 亚马逊云科技技术品牌专区