别再傻傻分页了！用MyBatis Cursor搞定百万数据导出，内存占用直降90%

百万级数据导出的性能革命：MyBatis Cursor实战解析

当系统需要处理百万级数据导出时，传统分页方案往往成为性能瓶颈的罪魁祸首。我曾在一个电商平台的订单导出功能中，亲眼见证分页查询导致的内存溢出——系统在导出50万条记录时直接崩溃。而改用MyBatis Cursor后，同样的数据量内存占用从4GB骤降到200MB，这种优化效果让整个技术团队为之震惊。本文将揭示这种技术转变背后的实现逻辑与实战技巧。

1. 传统分页方案的致命缺陷

分页查询看似是处理大数据集的通用解决方案，但在实际生产环境中暴露出的问题远比想象中严重。以某金融系统为例，导出100万条交易记录时，常规的LIMIT offset, size分页方式需要执行100次数据库查询，每次查询都伴随着全表扫描和临时表创建。

分页查询的三大核心问题：

1. 内存爆炸式增长：每次分页查询结果都完整加载到JVM内存中，100万条记录若每条1KB，总内存占用将达1GB
2. 深度分页性能悬崖：当offset超过10万时，MySQL需要先扫描并丢弃前10万条记录，查询耗时呈指数级上升
3. 数据一致性问题：在分页查询过程中，若源数据发生变化，可能导致记录重复或丢失

-- 典型的分页查询SQL（性能灾难） SELECT * FROM large_table ORDER BY id LIMIT 900000, 10000;

对比测试数据：

2. Cursor流式查询的实现原理

MyBatis Cursor的本质是JDBC ResultSet的迭代器封装，其核心优势在于按需加载机制。与一次性加载全部结果不同，它像拧开水龙头一样，让数据以可控的流速逐步进入应用内存。

技术实现关键点：

1. 数据库游标保持：底层依赖JDBC的TYPE_FORWARD_ONLY结果集类型，确保服务器端游标保持打开状态
2. 网络传输优化：默认每次从数据库网络缓冲区获取fetchSize条记录（Oracle默认10，MySQL需显式设置）
3. 内存控制阀：通过迭代器模式实现逐条处理，处理完的记录立即符合GC条件

配置MySQL fetch size的典型方式：

@Bean public ConfigurationCustomizer configurationCustomizer() { return configuration -> { configuration.setDefaultFetchSize(1000); // 设置每次网络传输的批处理量 }; }

注意：MySQL Connector/J驱动需要配合useCursorFetch=true参数才能生效，否则fetchSize设置会被忽略

3. Spring Boot集成Cursor的最佳实践

在实际项目中，需要解决两个关键问题：连接生命周期管理和事务边界控制。以下是经过多个生产项目验证的集成方案。

3.1 事务管理方案对比

方案一：声明式事务（推荐）

@Service public class ExportService { private final UserMapper userMapper; @Transactional public void exportUsers(OutputStream output) throws IOException { try (Cursor<User> cursor = userMapper.streamAll()) { CSVPrinter printer = new CSVPrinter(new OutputStreamWriter(output), CSVFormat.DEFAULT); cursor.forEach(user -> { try { printer.printRecord(user.getId(), user.getName(), user.getEmail()); } catch (IOException e) { throw new UncheckedIOException(e); } }); printer.flush(); } } }

方案二：编程式事务

@Service public class ExportService { private final UserMapper userMapper; private final TransactionTemplate transactionTemplate; public void exportUsers(OutputStream output) { transactionTemplate.execute(status -> { try (Cursor<User> cursor = userMapper.streamAll(); CSVPrinter printer = ...) { cursor.forEach(user -> processRecord(printer, user)); return null; } catch (IOException e) { throw new TransactionException("Export failed", e); } }); } }

连接保持方案对比表：

3.2 性能调优参数

在application.yml中配置关键参数：

spring: datasource: hikari: maximum-pool-size: 20 tomcat: max-active: 20 mybatis: configuration: default-fetch-size: 1000 local-cache-scope: statement

关键配置说明：

• default-fetch-size：控制每次从数据库获取的记录数，建议500-5000之间
• local-cache-scope：设置为statement避免二级缓存占用内存
• 连接池大小：需根据并发导出任务数调整，每个流式查询会独占一个连接

4. 生产环境中的陷阱与解决方案

在真实业务场景中，我们遇到过各种意外情况，以下是几个典型案例及其解决方案。

4.1 连接泄漏防护

即使使用try-with-resources，某些异常场景仍可能导致连接泄漏。我们开发了连接状态监控组件：

public class ConnectionMonitor { private static final ThreadLocal<AtomicInteger> cursorCount = ThreadLocal.withInitial(() -> new AtomicInteger(0)); public static void startCursor() { cursorCount.get().incrementAndGet(); } public static void endCursor() { cursorCount.get().decrementAndGet(); } public static void assertAllCursorsClosed() { if (cursorCount.get().get() > 0) { throw new IllegalStateException("存在未关闭的Cursor"); } } } // 在AOP中调用 @Aspect @Component public class ConnectionCheckAspect { @AfterReturning("execution(* com..export.*(..))") public void afterExport() { ConnectionMonitor.assertAllCursorsClosed(); } }

4.2 大数据类型处理

当表中包含BLOB/TEXT等大字段时，流式查询需要特殊处理：

@Transactional public void exportWithBlobs(OutputStream output) { try (Cursor<Document> cursor = docMapper.streamAll()) { cursor.forEach(doc -> { // 分批读取BLOB内容 try (InputStream is = doc.getContent().getBinaryStream()) { byte[] buffer = new byte[4096]; int bytesRead; while ((bytesRead = is.read(buffer)) != -1) { output.write(buffer, 0, bytesRead); } } }); } }

4.3 超时控制机制

长时间运行的导出任务需要超时保护：

@Transactional(timeout = 1800) // 30分钟超时 public void exportWithTimeout(OutputStream output) { try (Cursor<User> cursor = userMapper.streamAll()) { cursor.forEach(user -> { if (Thread.currentThread().isInterrupted()) { throw new ExportTimeoutException("导出超时终止"); } // 处理逻辑 }); } }

5. 高级应用场景

在复杂业务系统中，流式查询可以与其他技术栈结合实现更强大的功能。

5.1 与反应式编程结合

public Flux<User> streamUsersReactive() { return Flux.using( () -> userMapper.streamAll(), cursor -> Flux.fromIterable(() -> cursor.iterator()), Cursor::close ).subscribeOn(Schedulers.boundedElastic()); }

5.2 分布式导出方案

对于超大规模数据（亿级以上），可以采用分片流式处理：

public void distributedExport(String shardKey) { try (Cursor<User> cursor = userMapper.streamByShard(shardKey)) { cursor.forEach(user -> { kafkaTemplate.send("export-topic", serialize(user)); }); } }

5.3 内存映射文件优化

当需要本地缓存中间结果时，使用内存映射文件避免OOM：

@Transactional public void exportToMappedFile(File output) { try (RandomAccessFile raf = new RandomAccessFile(output, "rw"); FileChannel channel = raf.getChannel(); Cursor<User> cursor = userMapper.streamAll()) { MappedByteBuffer buffer = channel.map(FileChannel.MapMode.READ_WRITE, 0, 1_000_000_000); cursor.forEach(user -> { byte[] bytes = serialize(user); buffer.putInt(bytes.length); buffer.put(bytes); }); } }

在最近的一个数据迁移项目中，我们使用Cursor配合内存映射文件技术，成功在8GB内存的机器上完成了10亿条记录的格式转换和导出，整个过程内存占用始终稳定在1GB以下。这种技术组合特别适合资源受限但数据量庞大的场景。