服务端开发博客 | 后端架构 · 高并发 · 性能优化 · 微服务实战 👋🏼

引言 运营小妹发来消息："帮我导出最近半年的订单数据，要 Excel 格式，有 1000 多万条。" 你自信满满："小意思，十分钟搞定。" 启动导出任务，看了一眼进度条，2 分钟后接口直接挂了。 查看日志： java.lang.OutOfMemoryError: Java heap space 堆内存飙到了 4G，GC 把 CPU 跑满，服务假死。 你又试了试加 -Xmx8g——这次撑了 5 分钟，还是挂了。 这就是大数据导出的典型坑：MyBatis 默认一次性把结果加载到内存，1000 万条订单 × 每条 50 个字段 ≈ 5-8 个 G，直接爆。 本文从踩坑的代码出发，一步步演进到最终方案： MyBatis 流式查询 → ResultHandler 逐条处理 → CSV 分片 → SXSSF 流式 Excel 内存：4G → 200M。 一、踩坑现场：传统导出为什么 OOM 1.1 传统写法 @Service public class OrderExportService { @Autowired private OrderMapper orderMapper; /** * 运....

公司的日报任务每天半夜 2 点跑，统计前一天所有订单的销售额。代码逻辑很简单——SELECT * FROM orders WHERE date = '2026-06-30'，然后 for 循环逐条累加。平时几万条订单没问题，大促那天 300 万条订单，SELECT * 把 300 万行全部加载到了 JVM 堆里，直接 OOM。运维半夜被电话叫醒，手动分批 SQL 跑了一个小时才完成。 批处理的 OOM 跟文件下载的 OOM 原因一样——把全部数据一把梭进内存。 数据库能存那么大的表，不代表你的 JVM 堆能装下它。今天聊聊三种让批处理不再 OOM 的方法：流式查询、分片处理、游标分批提交。 问题：JDBC 默认是一次性加载全部结果集 MySQL 的 JDBC 驱动默认行为是：执行 SELECT 后，把所有结果行都拉到客户端内存里。你的代码写的虽然是 while (rs.next())，但在 next() 之前，数据已经在内存里了。 JDBC 默认行为： → 执行 SELECT → 100 万行全部加载到 ResultSet（JVM 堆） → while (rs.next()) 遍历....