MyBatis-Plus流式查询导致OOM问题的分析与解决方案

【免费下载链接】mybatis-plus mybatis 增强工具包，简化 CRUD 操作。 文档 http://baomidou.com 低代码组件库 http://aizuda.com 项目地址: https://gitcode.com/baomidou/mybatis-plus

问题背景

在使用MyBatis-Plus进行大数据量查询时，开发者可能会遇到内存溢出(OOM)的问题。特别是在处理千万级数据量的表时，传统的查询方式会将所有结果一次性加载到内存中，这显然不适合大数据量的场景。本文将以一个实际案例为基础，分析MyBatis-Plus流式查询的实现原理及解决方案。

问题现象

开发者在使用MyBatis-Plus 3.5.4版本时，尝试通过流式查询接口处理千万级数据量的表，但发现程序无法进入预期的断点位置，内存持续增长，最终导致OOM错误。从堆栈信息可以看出，错误发生在GC尝试回收内存时，达到了GC overhead limit exceeded的限制。

根本原因分析

经过深入分析，发现问题的根源在于MySQL流式查询的特殊实现机制。MySQL JDBC驱动要求必须满足以下三个条件才会启用真正的流式查询：

1. 结果集类型必须为FORWARD_ONLY（只能向前遍历）
2. 结果集并发模式必须为CONCUR_READ_ONLY（只读）
3. 获取大小(fetchSize)必须设置为Integer.MIN_VALUE(-2147483648)

如果这些条件不满足，即使调用了流式查询API，MySQL驱动仍然会尝试将所有结果加载到内存中，从而导致内存问题。

解决方案

方案一：配置全局默认fetchSize

在MyBatis-Plus配置中设置默认的fetchSize为Integer.MIN_VALUE：

mybatis-plus:
  configuration:
    default-fetch-size: -2147483648

这种方案适用于整个应用都需要使用流式查询的场景。

方案二：针对特定查询设置流式参数

对于特定的Mapper方法，可以通过注解或XML方式明确指定流式查询参数：

@Select("SELECT account_no, curr_bal, transaction_time FROM system_deposit_dynamics WHERE deleted = 0 AND (transaction_time <= #{time})")
@Options(resultSetType = ResultSetType.FORWARD_ONLY, fetchSize = Integer.MIN_VALUE)
@ResultType(DepositDynamics.class)
void selectLargeData(@Param("time") Date time, ResultHandler<DepositDynamics> handler);

或者在XML映射文件中：

<select id="selectLargeData" resultType="DepositDynamics" 
        fetchSize="-2147483648" resultSetType="FORWARD_ONLY">
    SELECT account_no, curr_bal, transaction_time 
    FROM system_deposit_dynamics 
    WHERE deleted = 0 AND (transaction_time <= #{time})
</select>

方案三：分页处理大数据量

对于特别大的数据集，可以考虑结合分页查询：

int pageSize = 5000;
int currentPage = 1;
while (true) {
    Page<DepositDynamics> page = new Page<>(currentPage, pageSize);
    IPage<DepositDynamics> result = depositDynamicsMapper.selectPage(page, queryWrapper);
    if (result.getRecords().isEmpty()) {
        break;
    }
    // 处理当前页数据
    currentPage++;
}

注意事项

1. 使用流式查询时，必须及时处理结果集中的数据，避免长时间占用数据库连接
2. 流式查询过程中，数据库连接必须保持打开状态，不能在处理完数据前关闭
3. 在使用ShardingJDBC等分库分表中间件时，流式查询的实现可能会有差异，需要特别注意
4. 对于特别大的数据集，建议考虑其他大数据处理方案，如数据导出、批处理等

最佳实践建议

1. 对于超过百万级别的数据查询，优先考虑使用专门的ETL工具或大数据处理框架
2. 在必须使用MyBatis-Plus处理大数据量时，明确区分是否真正需要流式处理
3. 为大数据量查询设置合理的超时时间和内存限制
4. 考虑使用缓存机制减少对数据库的直接大数据量查询

通过以上分析和解决方案，开发者可以有效地避免在使用MyBatis-Plus处理大数据量时出现的内存溢出问题，同时保证查询效率和系统稳定性。

【免费下载链接】mybatis-plus mybatis 增强工具包，简化 CRUD 操作。 文档 http://baomidou.com 低代码组件库 http://aizuda.com 项目地址: https://gitcode.com/baomidou/mybatis-plus