MyBatis 的一级缓存和二级缓存有什么区别？

一级缓存基于SqlSession，生命周期短，默认开启，提升单会话内重复查询性能；二级缓存基于Mapper命名空间，跨SqlSession共享，需手动配置，适用于读多写少场景，但分布式环境下需结合Redis等外部缓存保证一致性，二者均不能替代数据库查询。

MyBatis 的一级缓存和二级缓存，说到底，它们都是为了提升数据访问速度、减轻数据库压力而存在的，但它们的作用范围、生命周期和使用方式却大相径庭。简单来说，一级缓存是基于

SqlSession

Mapper

解决方案

理解MyBatis的缓存机制，就像理解不同层级的记忆。一级缓存（Local Cache）就像我们大脑的短期记忆，它与当前的

SqlSession

SqlSession

SqlSession

SqlSession

SqlSession

SqlSession

SqlSession

二级缓存（Global Cache），则更像是我们长期记忆中的某个特定主题区域。它与

Mapper

SqlSession

Mapper

SqlSession

mybatis-config.xml

Mapper.xml

Serializable

Mapper

MyBatis一级缓存为什么默认开启，它带来了哪些好处和潜在问题？

在我看来，MyBatis一级缓存之所以默认开启，更多的是出于一种“就近原则”和“事务内性能优化”的考量。你想想看，在一个事务或者一次业务操作中，我们经常会连续查询某条数据好几次，比如先查询用户详情，然后基于详情做一些判断，再可能因为某些逻辑需要再次确认用户状态。如果每次都去数据库跑一圈，那性能损耗会非常大。

好处显而易见：

• 性能提升： 这是最直接的。在同一个

  SqlSession

  内重复查询相同数据，可以显著减少数据库访问次数，降低数据库负载，提升响应速度。
• 简化开发： 默认开启，开发者无需额外配置，开箱即用，非常方便。它默默地在后台为我们优化，很多时候我们甚至都感觉不到它的存在。

但它也并非没有潜在问题，这往往体现在我们对

SqlSession

• 脏读风险（在特定场景下）： 严格来说，MyBatis在执行增删改操作时会清空一级缓存，这在一定程度上避免了脏读。但如果你在一个

  SqlSession

  中先查询了数据A，然后数据库外部（比如另一个应用实例或直接操作数据库）修改了数据A，而你在这个

  SqlSession

  中又没有执行任何增删改操作，再次查询数据A时，你仍然会从一级缓存中获取到旧数据。这并不是MyBatis的“错误”，而是我们对缓存机制和

  SqlSession

  生命周期理解不够深入导致的。
• 内存占用： 如果在单个

  SqlSession

  中查询了大量不同的数据，一级缓存可能会占用较多内存。虽然

  SqlSession

  的生命周期通常较短，这个问题一般不严重，但在某些极端情况下也需要注意。

MyBatis二级缓存如何配置和使用，它对分布式环境有什么影响？

配置和使用MyBatis的二级缓存，需要我们多做几步，但带来的好处也是跨会话的。首先，你需要确保全局配置中

cacheEnabled

true

Mapper.xml

    
    
        flushInterval="60000"   
        size="512"              
        readOnly="true"/>       

    
    
        SELECT * FROM users WHERE id = #{id}
    

你也可以指定自定义的缓存实现，比如集成Ehcache或Redis：

User

Serializable

MCP官网

Model Context Protocol（模型上下文协议）

下载

它对分布式环境的影响，这才是二级缓存最需要我们深思熟虑的地方。 MyBatis自带的二级缓存实现，默认是基于内存的，这意味着它只在单个应用实例中有效。如果你的应用部署在多个服务器上（也就是分布式环境），那么每个服务器都会有自己独立的二级缓存。

问题就来了： 假设服务器A更新了数据，它会清空自己本地的二级缓存。但服务器B、C、D的二级缓存并不知道这个更新，它们仍然可能提供旧的数据。这就导致了数据不一致性。

如何解决呢？

1. 使用分布式缓存： 最常见的做法是引入外部的分布式缓存系统，比如Redis、Memcached。你需要为MyBatis编写或使用社区提供的插件，将MyBatis的二级缓存委托给这些分布式缓存系统。这样，所有应用实例都共享同一个外部缓存，数据更新时，只需要在分布式缓存中失效即可，从而保证了数据的一致性。
2. 谨慎使用或禁用： 对于那些数据一致性要求极高、更新频繁的场景，或者你还没有准备好引入和管理分布式缓存，那么禁用二级缓存，或者只对那些几乎不变的“静态”数据开启，会是更稳妥的选择。

什么时候应该使用MyBatis的二级缓存，它能完全替代数据库查询吗？

要说什么时候应该用二级缓存，我个人觉得，这得看你的业务场景对“数据新鲜度”和“性能”的权衡。它不是万能药，更不是数据库的替代品。

理想的使用场景：

• 读多写少的数据： 比如一些配置信息、字典表、不经常变动的商品分类、行政区划等。这些数据被频繁查询，但更新频率极低，非常适合缓存。
• 对数据实时性要求不那么高的数据： 如果你的业务允许在短时间内（比如几秒到几分钟）读取到稍微旧一点的数据，那么二级缓存就能大显身手。
• 减轻数据库压力： 当你的数据库因为大量重复查询而负载过高时，二级缓存可以显著分担压力，让数据库专注于处理更复杂的事务。

但二级缓存绝不能，也永远无法，完全替代数据库查询。

• 数据是“源头”： 数据库是数据的最终来源和唯一权威。缓存只是数据库的“副本”，它永远存在数据滞后的风险。
• 一致性挑战： 尤其是在写操作频繁或分布式环境中，维护缓存与数据库之间的数据一致性是一个复杂且容易出错的挑战。你需要精心设计缓存失效策略，甚至引入消息队列来同步缓存状态。
• 缓存穿透、击穿、雪崩： 缓存本身也会引入新的问题。如果查询的数据不在缓存中，每次都去数据库查询（穿透）；缓存失效瞬间，大量请求涌入数据库（击穿）；大面积缓存失效导致数据库压力骤增甚至崩溃（雪崩）。这些都需要额外的策略来应对。
• 数据量和内存限制： 并不是所有数据都适合缓存。海量数据或者更新极其频繁的数据，缓存的维护成本可能远超收益，甚至可能导致缓存服务器内存溢出。

所以，二级缓存更像是一个性能优化的“加速器”，它工作在数据库的前面，通过牺牲一点点数据实时性来换取显著的性能提升。它永远是数据库的辅助，而不是替代品。在决定是否使用二级缓存时，务必结合你的业务特性、数据访问模式以及对数据一致性的容忍度来综合考量。