Mybatis中缓存机制的理解以及优缺点

MyBatis 提供了完善的缓存机制，用于减少了数据库访问次数，提升查询性能。其缓存体系分为一级缓存（本地缓存）和二级缓存（全局缓存），两者配合使用形成了 MyBatis 的缓存体系。

一、MyBatis 缓存机制详解

1. 一级缓存（Local Cache）

• 作用范围：SqlSession 级别（即同一个数据库会话内有效）。
• 实现原理：默认开启，无需配置。MyBatis 在 SqlSession 内部维护一个 HashMap 作为缓存容器，键为 CacheKey（由 SQL 语句、参数、RowBounds、环境等信息生成），值为查询结果。
• 生命周期：与 SqlSession 一致，当 SqlSession 关闭（close()）或提交（commit()）、回滚（rollback()）时，一级缓存会被清空。
• 触发场景：

• 同一 SqlSession 中，执行相同的查询（SQL 语句、参数、分页等完全一致），会直接从缓存获取结果，不执行 SQL。
• 若 SqlSession 中执行了增删改操作（insert/update/delete），MyBatis 会自动清空一级缓存，避免脏数据。

2. 二级缓存（Global Cache）

• 作用范围：Mapper 接口级别（跨 SqlSession 共享，多个 SqlSession 可共享同一 Mapper 的缓存）。
• 实现原理：默认关闭，需手动开启。开启后，MyBatis 会为每个 Mapper 接口创建一个缓存对象（可自定义缓存实现，如 Redis、EhCache 等），查询结果会先存入一级缓存，当 SqlSession 关闭时，一级缓存的数据会被刷入二级缓存。
• 开启方式：

1. 在 MyBatis 配置文件中开启全局二级缓存（默认 true，可省略）：

 ```xml<settings><setting name="cacheEnabled" value="true"/></settings>```

2. 在 Mapper 接口或 XML 中声明使用二级缓存：

 - XML 方式：在 Mapper.xml 中添加 `<cache/>` 标签。- 注解方式：在 Mapper 接口上添加 `@CacheNamespace` 注解。

• 缓存策略：可通过 <cache> 标签的属性配置，如 eviction（回收策略，如 LRU、FIFO）、flushInterval（自动刷新时间）、size（最大缓存条目）、readOnly（是否只读）等。
• 触发清空：当 Mapper 中执行增删改操作时，MyBatis 会清空该 Mapper 对应的二级缓存。

3. 缓存执行顺序

查询数据时，MyBatis 会按以下顺序查找缓存：
二级缓存 → 一级缓存 → 数据库

• 若二级缓存命中，直接返回结果。
• 若二级缓存未命中，查询一级缓存，命中则返回。
• 若一级缓存也未命中，执行 SQL 查询数据库，结果依次存入一级缓存和二级缓存（当 SqlSession 关闭时）。

二、MyBatis 缓存的优点

1. 减少数据库访问：缓存命中时无需执行 SQL，降低数据库压力，尤其适合高频查询、低频修改的数据（如商品分类、字典表）。
2. 提升查询性能：缓存查询为内存操作，响应速度远快于数据库 IO，可显著减少接口响应时间。
3. 一级缓存自动维护：无需手动配置，默认生效，适合单会话内的重复查询（如一次请求中多次查询同一用户信息）。
4. 二级缓存灵活性高：支持自定义缓存实现（如集成 Redis 实现分布式缓存），可根据业务需求配置回收策略、过期时间等。
5. 与事务兼容：增删改操作会自动清空相关缓存，减少脏数据风险（需正确使用）。

三、MyBatis 缓存的缺点

1. 一级缓存局限性：

• 仅在 SqlSession 内有效，多会话共享数据需依赖二级缓存。
• 若 SqlSession 未关闭，长时间持有缓存可能导致数据过期（如其他会话修改了数据，当前会话仍使用旧缓存）。

2. 二级缓存潜在问题：

• 脏数据风险：多表关联查询时，若关联表的数据在其他 Mapper 中修改，当前 Mapper 的二级缓存可能未同步更新，导致查询到脏数据。
  例如：OrderMapper 缓存了包含用户信息的订单数据，若 UserMapper 修改了用户信息，OrderMapper 的缓存仍为旧数据。
• 分布式环境不兼容：默认二级缓存为本地内存缓存，分布式系统中多节点缓存无法同步，可能导致数据不一致（需集成 Redis 等分布式缓存解决）。
• 缓存键设计复杂：CacheKey 依赖 SQL、参数、分页等信息，若查询条件细微差异（如参数顺序不同），会导致缓存不命中，浪费缓存空间。

3. 缓存维护成本：

• 需手动配置二级缓存，且需根据业务调整回收策略、过期时间等参数，增加开发成本。
• 对于高频修改的数据（如库存、订单状态），缓存命中率低，反而可能因缓存更新带来额外开销。

4. 调试难度增加：缓存的存在可能掩盖 SQL 性能问题（如慢查询因缓存命中未暴露），且排查缓存相关的脏数据问题较为复杂。

四、适用场景与最佳实践

• 适合使用缓存：

• 高频查询、低频修改的数据（如商品类目、地区信息、字典表）。
• 单表查询或关联关系简单的查询（避免多表关联导致的缓存不一致）。
• 分布式环境下，建议使用 Redis 等分布式缓存替代默认二级缓存。

• 不适合使用缓存：

• 高频修改的数据（如库存、实时销量）。
• 多表关联复杂的查询（难以保证缓存一致性）。
• 数据实时性要求极高的场景（如金融交易数据）。

• 最佳实践：

• 优先利用一级缓存，避免在 SqlSession 中执行无关操作，减少缓存无效清空。
• 二级缓存按需开启，对核心 Mapper 单独配置，避免全局开启导致的缓存膨胀。
• 多表关联查询时，可通过 @CacheNamespaceRef 关联相关 Mapper，确保缓存同步清空。
• 分布式系统中，集成 Redis 作为二级缓存，保证缓存一致性。

总结

MyBatis 缓存机制通过一级缓存和二级缓存的配合，有效提升了查询性能，但也存在缓存一致性、分布式兼容等问题。实际使用中需根据业务场景合理配置，权衡性能与数据准确性，避免滥用缓存导致的隐性问题。