当前位置：首页 > news >正文

【Mybatis】MyBatisPlus的saveBatch真的是批量插入吗？深度解析与性能优化

news 来源：原创 2025/4/26 5:18:30

前言

在使用MyBatis-Plus进行批量数据插入时，许多开发者会发现：即使调用saveBatch方法，数据库仍会产生大量INSERT语句。本文将深入源码揭示背后的真相，并提供3种性能优化方案，让你的批量插入速度提升10倍！

一、为什么批量插入这么慢？

1.1 性能测试对比

// 测试代码
List<User> users = generateUsers(10000); // 生成1w条测试数据
long start = System.currentTimeMillis();
userService.saveBatch(users);
System.out.println("耗时：" + (System.currentTimeMillis() - start) + "ms");// 测试结果
// 默认配置：耗时 3200ms
// 期待效果：耗时 < 500ms

1.2 SQL监控日志

-- 实际执行的SQL
INSERT INTO user (name,age) VALUES ('user1', 20);
INSERT INTO user (name,age) VALUES ('user2', 21);
...（重复1w次）

二、源码解析：揭开saveBatch的真面目

2.1 核心源码追踪

代码定位：ServiceImpl.saveBatch → SqlHelper.executeBatch

// 关键源码片段
public boolean saveBatch(Collection<T> entityList, int batchSize) {return executeBatch(entityList, batchSize, (sqlSession, entity) -> sqlSession.insert(sqlStatement, entity)); // 逐条插入
}

2.2 执行流程图示

2.3 慢速根源分析

关键因素	影响说明
SimpleExecutor	默认执行器逐条提交SQL
事务提交机制	默认自动提交（可优化）
JDBC网络开销	每次插入产生一次网络IO

三、性能优化方案

3.1 方案一：启用批量执行器（配置优化）

3.1.1 修改配置

mybatis-plus:configuration:default-executor-type: batch # 启用批量模式global-config:db-config:logic-delete-field: isDeleted # 避免逻辑删除干扰

3.1.2 效果验证

-- 批量插入SQL（真实执行）
INSERT INTO user (name, age) 
VALUES ('user1',20), ('user2',21)...;

性能提升：1w条数据插入从3200ms → 850ms

3.2 方案二：自定义批量SQL（终极优化）

3.2.1 扩展Mapper接口

public interface UserMapper extends BaseMapper<User> {@Insert("<script>" +"INSERT INTO user (name, age) VALUES " +"<foreach collection='list' item='item' separator=','>" +"(#{item.name}, #{item.age})" +"</foreach>" +"</script>")void insertBatch(@Param("list") List<User> users);
}

3.2.2 服务层调用

@Autowired
private UserMapper userMapper;public void superBatchSave(List<User> users) {userMapper.insertBatch(users);
}

性能对比：1w条数据插入仅需420ms

3.3 方案三：事务+分批提交（平衡方案）

@Transactional
public void batchSave(List<User> users) {int batchSize = 1000;for (int i = 0; i < users.size(); i += batchSize) {List<User> subList = users.subList(i, Math.min(i + batchSize, users.size()));userService.saveBatch(subList);}
}

优势：
✅ 避免大事务导致锁表
✅ 内存占用可控
✅ 兼容默认实现

四、生产环境注意事项

4.1 连接池配置

spring:datasource:hikari:maximum-pool-size: 20 # 根据并发量调整connection-timeout: 60000

4.2 监控指标

监控项	推荐阈值	工具
批量插入耗时	< 1s/千条	Grafana + Prometheus
数据库连接数	< 80%最大连接数	Druid监控
事务锁等待时间	< 500ms	SHOW ENGINE INNODB STATUS

4.3 失败重试机制

@Retryable(value = SQLException.class, maxAttempts = 3)
public void batchOperation() {// 批量操作
}

五、性能对比总结

方案	1w条耗时	网络请求次数	代码侵入性	适用场景
默认saveBatch	3200ms	10000	无	小数据量场景
BatchExecutor	850ms	1	低	中大数据量
自定义批量SQL	420ms	1	高	极致性能要求
事务分批提交	1500ms	10	中	平衡型方案