登录注册

当前位置：首页 > 文章列表 > 文章 > java教程 > MyBatis一级缓存一致性风险解析

MyBatis一级缓存一致性风险解析

2026-03-12 13:06:38 0浏览 收藏
MyBatis一级缓存虽默认开启、能减少重复查询开销，却因仅绑定单个SqlSession且完全无法感知其他会话对数据库的修改，极易引发隐蔽而严重的数据不一致问题——例如同一事务中先查后由其他服务更新，缓存仍返回过期结果；它既不能自动刷新，也不支持关闭，仅靠手动清空或写操作触发失效，而在分布式、多服务协作或强一致性要求场景（如金融交易、状态审核）下尤为危险；因此，开发者不应将其视为可靠优化手段，而应优先通过合理管理SqlSession生命周期、依赖事务隔离级别或引入版本控制来保障数据准确，真正理解其窄边界与高风险，才是安全使用MyBatis的关键。

如何评估MyBatis的一级缓存带来的副作用_多次查询相同数据可能引发的数据一致性问题

MyBatis 一级缓存默认开启，但只在同一个 SqlSession 内生效

一级缓存不是“全局共享”的缓存，它绑定在单个 SqlSession 实例上。只要没关闭或手动清空，同一 SqlSession 中重复执行相同 select 语句（参数、SQL 完全一致），就会直接返回缓存结果，跳过数据库查询。

这看起来省资源，但副作用就藏在这里：如果中间有其他线程或代码通过别的 SqlSession 修改了数据库，当前 SqlSession 是完全感知不到的——它还拿着旧数据。

  • 常见错误现象：select * from user where id = 1 第一次查到 name=“张三”，之后另一服务更新了该记录为“李四”，本 session 再次执行同样语句，仍返回“张三”
  • 典型使用场景：Web 请求中复用 SqlSession（比如手动管理而非 Spring 的 SqlSessionTemplate）、批处理循环中反复查同一条记录
  • 注意 SqlSession 生命周期：Spring 默认每个方法调用新建一个，所以一级缓存通常“跨不过方法边界”；但如果用了 @Transactional 且传播行为是 REQUIRED，整个事务共用一个 SqlSession，风险就明显上升

什么时候一级缓存会失效？别指望它自动同步

一级缓存不是靠监听或轮询来刷新的，它的失效完全依赖显式操作或隐式触发点。一旦缓存失效，下次查询才会重新访问数据库。

  • 显式清空：sqlSession.clearCache() 或 sqlSession.commit()/sqlSession.rollback() 都会清掉缓存
  • 隐式清空：任何 insert/update/delete 语句执行后，MyBatis 会自动清空当前 SqlSession 的一级缓存（防止读到脏数据）——但仅限于本 session 内的写操作
  • 容易踩的坑：在事务中先 select，再调用另一个 service 方法（它内部也用了 SqlSession 并做了 update），但这个 update 发生在另一个 session，对当前 session 的缓存毫无影响

如何验证一级缓存是否真的在起作用？

别靠猜，用日志和调试直观看。MyBatis 默认不打 SQL 日志，需要显式配置才能确认是否走了缓存。

  • 开启 MyBatis 日志（如用 Log4j2）：logging.level.org.apache.ibatis=DEBUG，然后观察控制台输出：缓存命中时不会出现 JDBC Connection 或 Preparing: SELECT ... 日志行
  • 更可靠的方式是在 DAO 层加断点，检查 SqlSession 对象的 localCache（PerpetualCache）是否已存入对应 key；key 是 MappedStatement ID + 参数 + 分页等组合的哈希值
  • 注意：开启二级缓存后，一级缓存行为不变，但日志可能混淆——要区分清楚日志里写的是 “Cache Hit”（二级）还是根本没打印 SQL（一级）

要不要禁用一级缓存？看你的数据一致性要求

一级缓存无法关闭（MyBatis 没提供开关），但可以绕过它。这不是性能优化手段，而是规避风险的务实做法。

  • 最稳妥的做法：每次查询都用新 SqlSession（Spring 中即避免手动传递/复用 session）
  • 临时绕过：在 Mapper 接口方法上加 @Options(flushCache = Options.FlushCachePolicy.TRUE)，或 XML 中给