一级缓存基于SqlSession，生命周期短，默认开启，提升单会话内重复查询性能；二级缓存基于Mapper命名空间，跨SqlSession共享，需手动配置，适用于读多写少场景，但分布式环境下需结合Redis等外部缓存保证一致性，二者均不能替代数据库查询。
MyBatis 的一级缓存和二级缓存，说到底，它们都是为了提升数据访问速度、减轻数据库压力而存在的，但它们的作用范围、生命周期和使用方式却大相径庭。简单来说，一级缓存是基于
SqlSession的，生命周期很短，默认就开启了；而二级缓存则是基于
Mapper的，生命周期更长，但需要我们手动去开启和配置。
解决方案
理解MyBatis的缓存机制，就像理解不同层级的记忆。一级缓存（Local Cache）就像我们大脑的短期记忆，它与当前的
SqlSession绑定。当你在一个
SqlSession中执行查询操作时，MyBatis会把查询结果存到这个
SqlSession的内部缓存里。如果后续在这个同一个
SqlSession中，再次执行完全相同的查询（包括SQL语句和参数），MyBatis就不会再去触碰数据库，而是直接从一级缓存中取出结果。它的生命周期与
SqlSession相同，
SqlSession关闭、提交或回滚时，一级缓存就会被清空。这是MyBatis为了避免在一次数据库会话中重复查询相同数据而做的优化，默认开启，你几乎不用关心它。但这也意味着，不同
SqlSession之间是无法共享一级缓存的。
二级缓存（Global Cache），则更像是我们长期记忆中的某个特定主题区域。它与
Mapper的命名空间绑定，是跨
SqlSession共享的。这意味着，只要是查询同一个
Mapper下的数据，并且开启了二级缓存，那么即使是不同的
SqlSession，也能共享这份缓存数据。它的生命周期更长，可以配置在应用程序的整个运行周期内有效。但二级缓存默认是关闭的，需要我们手动在
mybatis-config.xml中全局开启，并在对应的
Mapper.xml文件中配置
<cache/>标签。要使用二级缓存，缓存的Java对象必须实现
Serializable接口，因为缓存的数据可能需要被序列化存储。每次对数据库的增删改操作，都会导致对应
Mapper的二级缓存失效，以保证数据的一致性。
MyBatis一级缓存为什么默认开启，它带来了哪些好处和潜在问题？
在我看来，MyBatis一级缓存之所以默认开启，更多的是出于一种“就近原则”和“事务内性能优化”的考量。你想想看，在一个事务或者一次业务操作中，我们经常会连续查询某条数据好几次，比如先查询用户详情，然后基于详情做一些判断，再可能因为某些逻辑需要再次确认用户状态。如果每次都去数据库跑一圈，那性能损耗会非常大。
好处显而易见：
-
性能提升： 这是最直接的。在同一个
SqlSession
内重复查询相同数据，可以显著减少数据库访问次数，降低数据库负载，提升响应速度。 - 简化开发： 默认开启，开发者无需额外配置，开箱即用，非常方便。它默默地在后台为我们优化，很多时候我们甚至都感觉不到它的存在。
但它也并非没有潜在问题，这往往体现在我们对SqlSession
生命周期管理不当的时候：
-
脏读风险（在特定场景下）： 严格来说，MyBatis在执行增删改操作时会清空一级缓存，这在一定程度上避免了脏读。但如果你在一个
SqlSession
中先查询了数据A，然后数据库外部（比如另一个应用实例或直接操作数据库）修改了数据A，而你在这个SqlSession
中又没有执行任何增删改操作，再次查询数据A时，你仍然会从一级缓存中获取到旧数据。这并不是MyBatis的“错误”，而是我们对缓存机制和SqlSession
生命周期理解不够深入导致的。 -
内存占用： 如果在单个
SqlSession
中查询了大量不同的数据，一级缓存可能会占用较多内存。虽然SqlSession
的生命周期通常较短，这个问题一般不严重，但在某些极端情况下也需要注意。
MyBatis二级缓存如何配置和使用，它对分布式环境有什么影响？
配置和使用MyBatis的二级缓存，需要我们多做几步，但带来的好处也是跨会话的。首先，你需要确保全局配置中
cacheEnabled为
true（默认就是）。接着，在你的
Mapper.xml文件中，简单地添加一个
<cache/>标签就行了，比如：
<mapper namespace="com.example.UserMapper">
<!-- 启用二级缓存 -->
<cache
eviction="LRU" <!-- 缓存回收策略：LRU, FIFO, SOFT, WEAK -->
flushInterval="60000" <!-- 缓存刷新间隔，单位毫秒，这里是60秒 -->
size="512" <!-- 缓存对象数量上限 -->
readOnly="true"/> <!-- 是否只读，true表示缓存对象是只读的，可以安全地共享，性能更好；false表示读写，会返回对象的拷贝，更安全但性能稍差 -->
<!-- 你的SQL查询语句 -->
<select id="getUserById" resultType="User">
SELECT * FROM users WHERE id = #{id}
</select>
</mapper>你也可以指定自定义的缓存实现，比如集成Ehcache或Redis：
<cache type="org.mybatis.caches.ehcache.EhcacheCache"/>。当然，别忘了你的实体类
User需要实现
Serializable接口。
它对分布式环境的影响，这才是二级缓存最需要我们深思熟虑的地方。 MyBatis自带的二级缓存实现，默认是基于内存的，这意味着它只在单个应用实例中有效。如果你的应用部署在多个服务器上（也就是分布式环境），那么每个服务器都会有自己独立的二级缓存。
问题就来了： 假设服务器A更新了数据，它会清空自己本地的二级缓存。但服务器B、C、D的二级缓存并不知道这个更新，它们仍然可能提供旧的数据。这就导致了数据不一致性。
如何解决呢？
- 使用分布式缓存： 最常见的做法是引入外部的分布式缓存系统，比如Redis、Memcached。你需要为MyBatis编写或使用社区提供的插件，将MyBatis的二级缓存委托给这些分布式缓存系统。这样，所有应用实例都共享同一个外部缓存，数据更新时，只需要在分布式缓存中失效即可，从而保证了数据的一致性。
- 谨慎使用或禁用： 对于那些数据一致性要求极高、更新频繁的场景，或者你还没有准备好引入和管理分布式缓存，那么禁用二级缓存，或者只对那些几乎不变的“静态”数据开启，会是更稳妥的选择。
什么时候应该使用MyBatis的二级缓存，它能完全替代数据库查询吗？
要说什么时候应该用二级缓存，我个人觉得，这得看你的业务场景对“数据新鲜度”和“性能”的权衡。它不是万能药，更不是数据库的替代品。
理想的使用场景：
- 读多写少的数据： 比如一些配置信息、字典表、不经常变动的商品分类、行政区划等。这些数据被频繁查询，但更新频率极低，非常适合缓存。
- 对数据实时性要求不那么高的数据： 如果你的业务允许在短时间内（比如几秒到几分钟）读取到稍微旧一点的数据，那么二级缓存就能大显身手。
- 减轻数据库压力： 当你的数据库因为大量重复查询而负载过高时，二级缓存可以显著分担压力，让数据库专注于处理更复杂的事务。
但二级缓存绝不能，也永远无法，完全替代数据库查询。
- 数据是“源头”： 数据库是数据的最终来源和唯一权威。缓存只是数据库的“副本”，它永远存在数据滞后的风险。
- 一致性挑战： 尤其是在写操作频繁或分布式环境中，维护缓存与数据库之间的数据一致性是一个复杂且容易出错的挑战。你需要精心设计缓存失效策略，甚至引入消息队列来同步缓存状态。
- 缓存穿透、击穿、雪崩： 缓存本身也会引入新的问题。如果查询的数据不在缓存中，每次都去数据库查询（穿透）；缓存失效瞬间，大量请求涌入数据库（击穿）；大面积缓存失效导致数据库压力骤增甚至崩溃（雪崩）。这些都需要额外的策略来应对。
- 数据量和内存限制： 并不是所有数据都适合缓存。海量数据或者更新极其频繁的数据，缓存的维护成本可能远超收益，甚至可能导致缓存服务器内存溢出。
所以，二级缓存更像是一个性能优化的“加速器”，它工作在数据库的前面，通过牺牲一点点数据实时性来换取显著的性能提升。它永远是数据库的辅助，而不是替代品。在决定是否使用二级缓存时，务必结合你的业务特性、数据访问模式以及对数据一致性的容忍度来综合考量。
