MyBatis一级缓存默认开启且仅限单个SqlSession内生效，重复查询相同语句直接返回缓存结果；但无法感知其他SqlSession的数据库变更，存在数据不一致风险，需谨慎使用。
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 是MappedStatementID + 参数 + 分页等组合的哈希值 - 注意：开启二级缓存后，一级缓存行为不变，但日志可能混淆——要区分清楚日志里写的是 “Cache Hit”（二级）还是根本没打印 SQL（一级）
要不要禁用一级缓存？看你的数据一致性要求
一级缓存无法关闭（MyBatis 没提供开关），但可以绕过它。这不是性能优化手段，而是规避风险的务实做法。
- 最稳妥的做法：每次查询都用新
SqlSession（Spring 中即避免手动传递/复用 session） - 临时绕过：在
Mapper接口方法上加@Options(flushCache = Options.FlushCachePolicy.TRUE)，或 XML 中给<select></select>加flushCache="true"——但这其实是“查前先清缓存”，治标不治本 - 真正关键的一点：如果你的应用要求“强一致性读”，比如金融类查询、审核流程中的状态校验，一级缓存就不该成为信任对象；此时应依赖数据库事务隔离级别，或引入显式版本号 / 时间戳校验
一级缓存的边界非常窄——它只在单次 session、无外部变更、无跨 session 协作的前提下才安全。现实系统里，这三个条件往往同时成立的概率很低。
