MyBatis批量插入性能优化实战

1. 项目背景与问题定位

去年接手一个数据迁移项目时，我遇到了一个典型的生产环境性能瓶颈：系统需要将十万级商品数据从旧库迁移到新库，使用MyBatis的简单循环插入方案耗时高达5分钟。这直接影响了夜间批处理任务的执行窗口，甚至导致后续依赖该数据的报表生成延迟。通过Arthas监控发现，95%的时间消耗在JDBC网络IO和事务提交上，单条提交的方式产生了严重的性能浪费。

这种场景在电商大促预热、物流订单同步、金融交易对账等业务中十分常见。当数据量超过万级时，传统的for循环+单条insert模式会产生三大致命问题：1) 网络往返开销呈指数增长 2) 事务日志写入过于频繁 3) 数据库连接利用率低下。以MySQL为例，每次插入都伴随完整的SQL解析、执行计划生成、锁竞争检查等流程，这种重复消耗在批量场景下显得极不经济。

2. 核心优化方案对比

2.1 原生批量插入模式

MyBatis内置的ExecutorType.BATCH模式是最容易想到的解决方案。通过改写SqlSession使用方式，可以实现语句预编译和参数批量传递：

java复制try (SqlSession session = sqlSessionFactory.openSession(ExecutorType.BATCH)) {
    Mapper mapper = session.getMapper(Mapper.class);
    for (Item item : itemList) {
        mapper.insert(item);
    }
    session.commit(); // 最终统一提交
}

实测万级数据插入时，该方案比普通模式快3-5倍。但其本质仍是发送多条独立INSERT语句，只是利用JDBC的addBatch机制减少了网络开销。在MySQL的JDBC驱动中，默认不会真正批量执行，除非配置rewriteBatchedStatements=true参数。这个隐藏细节让很多开发者误以为使用了批量插入，实际性能提升有限。

2.2 动态SQL拼接方案

更激进的做法是采用<foreach>标签拼接巨型SQL：

xml复制<insert id="batchInsert">
    INSERT INTO items(id,name,price) VALUES
    <foreach collection="list" item="item" separator=",">
        (#{item.id},#{item.name},#{item.price})
    </foreach>
</insert>

这种方案在数据量较小时（千级以内）表现优异，单次网络交互完成所有操作。但存在两个明显缺陷：1) SQL长度可能超过数据库限制（MySQL默认4MB） 2) 锁持有时间过长可能引发阻塞。曾有个案例：某次批量插入5万条数据导致SQL长达2.3MB，不仅执行缓慢还触发了数据库的OOM保护机制。

2.3 多值插入语法优化

MySQL 5.7+和Oracle 12c开始支持更高效的多值插入语法：

sql复制INSERT INTO items(id,name,price) 
VALUES (1,'商品A',100), (2,'商品B',200) 
ON DUPLICATE KEY UPDATE name=VALUES(name);

配合MyBatis的动态SQL，可以结合分批策略控制单次插入量。以下是经过生产验证的参数配置经验值：

• MySQL：每批1000-2000条（包大小控制在1MB内）
• Oracle：每批500-1000条（避免UNDO表空间暴涨）
• PostgreSQL：每批2000-3000条（利用其优秀的批量处理能力）

3. 工程化实现细节

3.1 智能分批处理算法

直接全量批量插入存在内存溢出风险，需要实现可靠的分批机制。我们开发了具备以下特性的分片处理器：

java复制public class BatchSlicer<T> {
    private static final int MAX_BATCH_SIZE = 1000;
    
    public void process(List<T> data, Consumer<List<T>> consumer) {
        int total = data.size();
        for (int from = 0; from < total; from += MAX_BATCH_SIZE) {
            int to = Math.min(from + MAX_BATCH_SIZE, total);
            List<T> subList = data.subList(from, to);
            // 增加重试机制
            RetryTemplate.execute(() -> consumer.accept(subList));
        }
    }
}

关键改进点包括：

1. 动态计算分片大小（根据字段平均字节数调整）
2. 失败批次自动记录并重试
3. 添加进度监控埋点

3.2 连接池与事务优化

批量操作对连接池配置有特殊要求。对比测试发现，当使用HikariCP时，以下配置能最大化吞吐量：

properties复制# 关键配置参数
spring.datasource.hikari.maximum-pool-size=50
spring.datasource.hikari.minimum-idle=10
spring.datasource.hikari.connection-timeout=30000
spring.datasource.hikari.idle-timeout=600000

事务管理建议采用PROPAGATION_REQUIRES_NEW隔离每个批次，避免单个失败导致全量回滚。Spring环境下可通过注解实现：

java复制@Transactional(propagation = Propagation.REQUIRES_NEW)
public void batchInsert(List<Item> items) {
    // 分批插入逻辑
}

4. 性能对比与生产验证

在相同硬件环境下（16C32G, MySQL 8.0.25），对10万条商品数据进行测试：

生产环境实施时还需注意：

1. 避开数据库高峰期执行
2. 监控InnoDB缓冲池命中率
3. 提前评估binlog增长量

5. 异常处理与监控

批量操作必须建立完善的容错机制。我们设计的异常处理流程包含：

1. 数据校验阶段：使用Bean Validation过滤非法数据
2. 执行阶段：捕获BatchUpdateException解析错误码
3. 补偿阶段：记录失败数据并提供重试接口

通过Micrometer暴露关键指标：

java复制Metrics.counter("batch.insert.total").increment();
Metrics.timer("batch.insert.latency").record(duration);

在Grafana中配置以下监控看板：

• 批次处理速率（条/秒）
• 失败批次比例
• 数据库主从延迟

6. 高级优化技巧

对于超大规模数据（百万级+），可考虑以下进阶方案：

1. LOAD DATA INFILE：MySQL原生文件导入方式，速度比SQL插入快10倍以上。需要先将数据转换为CSV格式，注意字段转义问题。

2. 多线程分片：结合线程池实现并行插入，注意控制并发度避免拖垮数据库：

java复制ExecutorService executor = Executors.newFixedThreadPool(8);
List<Future<?>> futures = new ArrayList<>();
for (List<Item> slice : ListUtils.partition(data, 5000)) {
    futures.add(executor.submit(() -> batchInsert(slice)));
}
// 等待所有任务完成
for (Future<?> future : futures) {
    future.get();
}

3. 表空间预热：在Oracle环境中，提前扩展表空间文件避免自动扩展带来的性能抖动。

7. ORM框架的局限性

尽管通过优化可以将MyBatis批量插入性能提升近百倍，但当遇到以下场景时，建议考虑其他方案：

1. 需要插入的同时返回自增ID（批量插入难以获取各记录的ID）
2. 数据量超过千万级（考虑Spark等分布式处理工具）
3. 需要复杂的数据转换逻辑（ETL工具更合适）

最近在处理一个日增量500万+的日志表时，我们最终采用了Spark JDBC写入方案，相比优化后的MyBatis批量插入，吞吐量又提升了8倍。技术选型需要根据具体场景权衡，没有放之四海而皆准的银弹方案。