MyBatis-Plus批量插入操作缓存刷新问题解析
项目地址: https://gitcode.com/baomidou/mybatis-plus 引言：批量插入的性能陷阱
在日常开发中，批量插入（Batch Insert）是提升数据库操作性能的重要手段。然而，很多开发者在MyBatis-Plus中使用批量插入功能时，经常会遇到一些意想不到的问题：数据不一致、主键冲突、缓存污染等。这些问题往往源于对MyBatis缓存机制和批量操作执行流程的理解不足。
本文将深入剖析MyBatis-Plus批量插入操作中的缓存刷新问题，通过源码分析、场景复现和解决方案，帮助开发者彻底理解并规避这些陷阱。
一、MyBatis缓存机制基础
1.1 一级缓存（Local Cache）
MyBatis的一级缓存是SqlSession级别的缓存，默认开启。在同一个SqlSession中执行相同的SQL语句时，会直接从缓存中获取结果，避免重复查询数据库。
1.2 二级缓存（Second Level Cache）
二级缓存是Mapper级别的缓存，多个SqlSession可以共享。需要手动配置开启，适用于读多写少的场景。
二、MyBatis-Plus批量插入实现原理
2.1 批量插入核心类
MyBatis-Plus通过MybatisBatchUtils和MybatisBatch类提供批量操作支持：
// 核心批量执行方法
public static <T> List<BatchResult> execute(SqlSessionFactory sqlSessionFactory,
Collection<T> dataList,
String statement) {
return new MybatisBatch<>(sqlSessionFactory, dataList).execute(statement);
}
2.2 批量插入执行流程
三、缓存刷新问题的典型场景
3.1 场景一：saveOrUpdate中的缓存污染
在批量保存或更新操作中，如果在判断条件中执行查询操作，可能会遇到一级缓存问题：
// 问题代码示例
MybatisBatchUtils.saveOrUpdate(sqlSessionFactory, dataList,
insertMethod,
(session, data) -> {
// 这里执行查询操作，可能受到一级缓存影响
Demo existing = demoMapper.selectById(data.getId());
return existing == null;
},
updateMethod);
问题分析：在同一个SqlSession中，如果第一次查询某个ID返回null，由于一级缓存的存在，后续相同的查询都会返回null，导致应该执行更新的操作错误地执行了插入。
3.2 场景二：批次间的缓存状态不一致
// 批次处理示例
try (SqlSession sqlSession = sqlSessionFactory.openSession(ExecutorType.BATCH)) {
List<List<Demo>> batches = CollectionUtils.split(dataList, 1000);
for (List<Demo> batch : batches) {
for (Demo data : batch) {
sqlSession.insert("com.example.mapper.DemoMapper.insert", data);
}
sqlSession.flushStatements(); // 刷新批处理
// 此处缓存状态可能影响后续操作
}
sqlSession.commit();
}
四、源码深度解析
4.1 flushStatements的关键作用
在MybatisBatch类的execute方法中，flushStatements()调用至关重要：
public List<BatchResult> execute(boolean autoCommit, String statement, ParameterConvert<T> parameterConvert) {
List<BatchResult> resultList = new ArrayList<>(dataList.size());
try (SqlSession sqlSession = sqlSessionFactory.openSession(ExecutorType.BATCH, autoCommit)) {
List<List<T>> split = CollectionUtils.split(dataList, batchSize);
for (List<T> splitedList : split) {
for (T data : splitedList) {
sqlSession.update(statement, toParameter(parameterConvert, data));
}
// 关键代码：刷新批处理语句
resultList.addAll(sqlSession.flushStatements());
if (!autoCommit) {
sqlSession.commit();
}
}
return resultList;
}
}
4.2 BatchSqlSession的缓存处理
BatchSqlSession包装了原始SqlSession，在每次select操作时都会触发flushStatements()：
public class BatchSqlSession {
private final SqlSession sqlSession;
private final List<BatchResult> resultBatchList = new ArrayList<>();
public <E> E selectOne(String statement, Object parameter) {
resultBatchList.addAll(sqlSession.flushStatements());
return sqlSession.selectOne(statement, parameter);
}
}
这种设计确保了在查询操作前清空批处理缓存，避免数据状态不一致。
五、解决方案与最佳实践
5.1 方案一：正确使用BatchSqlSession
对于需要查询判断的批量操作，使用BatchSqlSession包装：
MybatisBatchUtils.saveOrUpdate(sqlSessionFactory, dataList,
insertMethod,
(batchSession, data) -> {
// 使用BatchSqlSession进行查询，会自动flush批处理
Demo existing = batchSession.selectOne(
"com.example.mapper.DemoMapper.selectById",
data.getId()
);
return existing == null;
},
updateMethod);
5.2 方案二：手动控制缓存状态
在需要的时候手动清除一级缓存：
public void clearLocalCache(SqlSession sqlSession) {
if (sqlSession != null) {
// 通过执行任意更新操作来清空缓存
sqlSession.update("任意Mapper方法", null);
}
}
5.3 方案三：合理设置批次大小
根据数据特性和业务需求，合理设置批次大小：
| 数据量 | 推荐批次大小 | 说明 |
|---|---|---|
| < 1000 | 100-200 | 小数据量，适中批次 |
| 1000-10000 | 500-1000 | 中等数据量，较大批次 |
| > 10000 | 1000-2000 | 大数据量，需要权衡内存和性能 |
5.4 方案四：事务边界控制
@Transactional
public void batchInsertWithTransaction(List<Demo> dataList) {
// 在事务方法中使用批量操作
MybatisBatchUtils.execute(sqlSessionFactory, dataList,
"com.example.mapper.DemoMapper.insert");
// 如果需要立即看到插入结果，可以手动刷新
// ((SqlSession) entityManager.unwrap(SqlSession.class)).flushStatements();
}
六、性能优化建议
6.1 批处理参数调优
# application.yml配置
mybatis-plus:
configuration:
default-executor-type: batch
cache-enabled: false # 批量操作时建议关闭二级缓存
6.2 监控与诊断
使用P6Spy或类似的SQL监控工具来观察批量操作的执行情况：
// 添加SQL日志监控
@Bean
public PerformanceInterceptor performanceInterceptor() {
PerformanceInterceptor interceptor = new PerformanceInterceptor();
interceptor.setMaxTime(1000); // 最大执行时间
interceptor.setFormat(true); // 格式化SQL
return interceptor;
}
七、常见问题排查表
| 问题现象 | 可能原因 | 解决方案 |
|---|---|---|
| 主键冲突 | 一级缓存导致重复查询返回相同结果 | 使用BatchSqlSession或手动清空缓存 |
| 数据不一致 | 批次间缓存状态污染 | 合理设置flushStatements调用时机 |
| 性能下降 | 批次大小不合理 | 根据数据量调整批次大小 |
| 内存溢出 | 单批次数据量过大 | 分批次处理，控制内存使用 |
八、总结
MyBatis-Plus的批量插入操作在提升性能的同时，也带来了缓存管理的复杂性。理解MyBatis的缓存机制、掌握flushStatements的调用时机、合理使用BatchSqlSession是避免缓存刷新问题的关键。
核心要点总结：
- 一级缓存是SqlSession级别的，批量操作中需要注意其影响
- flushStatements用于刷新批处理语句，同时会影响缓存状态
- BatchSqlSession在查询时会自动flush批处理，避免缓存污染
- 合理设置批次大小和事务边界对性能至关重要
通过本文的分析和解决方案，开发者应该能够更好地理解和处理MyBatis-Plus批量插入中的缓存刷新问题，构建更加稳定高效的数据持久层。
温馨提示：在实际项目中，建议结合具体的业务场景和数据特性来选择合适的批量处理策略，并在测试环境中充分验证其正确性和性能表现。
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
