1. 从一次线上查询超时说起为什么我们需要关注MyBatis缓存那天下午监控系统突然告警一个核心的订单详情接口响应时间从平时的50ms飙升至5秒以上。我们紧急排查数据库负载正常SQL执行计划也没问题最后定位到问题出在应用层——一个被高频调用的getOrderById方法。这个方法逻辑很简单就是根据ID从数据库查一条记录。在压力测试时我们明明看到它很快为什么线上就慢了呢深入代码发现这个方法在一个循环中被调用了上百次每次调用都“看似”独立地执行了一次数据库查询。问题的根源就在于开发者对MyBatis的缓存机制一无所知或者说没有正确地理解和利用它。如果当时正确配置并理解了MyBatis的三级缓存这次事故完全可以避免数据库的压力也能大幅降低。这就是我们今天要深入探讨的MyBatis三级缓存。它绝不仅仅是配置文件里的几个开关而是一个贯穿SqlSession生命周期、甚至应用生命周期的性能优化体系。理解它你就能写出更高效、更健壮的数据库访问代码忽视它你可能就会埋下我们刚刚提到的性能陷阱甚至是更棘手的数据一致性问题。简单来说MyBatis的三级缓存为我们提供了三层数据暂存区一级缓存也叫本地缓存Local Cache它的作用域是一个SqlSession。在同一个SqlSession中执行相同的查询MyBatis会直接从内存返回结果而不会再次访问数据库。二级缓存它的作用域是一个Mapper的命名空间Namespace可以跨SqlSession共享。当多个SqlSession操作同一个Mapper时它们可以共享缓存数据。三级缓存这是一个更宽泛的概念指的是整合外部缓存中间件如Redis、Ehcache等实现应用级甚至分布式级别的缓存共享。接下来我们将一层层剥开它的面纱不仅告诉你它是什么、怎么用更重要的是结合我踩过的坑告诉你为什么这么设计以及在实际生产中如何权衡利弊、规避风险。2. 一级缓存SqlSession级别的“私人备忘录”你可以把一级缓存想象成每个SqlSession自带的“私人备忘录”。当这个SqlSession执行一条查询语句后它会把结果记在自己的小本本缓存上。如果紧接着在同一个SqlSession里又执行了一模一样的查询它就不会再去麻烦数据库执行SQL而是直接从小本本上把结果抄过来。2.1 一级缓存的工作原理与生命周期一级缓存是默认开启的你不需要做任何配置。它的实现非常直接底层就是一个简单的HashMap存储的Key是CacheKey对象。这个CacheKey由哪些因素决定呢它是由以下元素共同计算出来的Mapper Statement的ID即命名空间方法名。查询的偏移量offset和限制条数limit即分页参数。本次查询所生成的SQL语句。传递给SQL的实际参数值。环境ID如果你的配置了多个数据源环境。只有当以上所有条件都完全一致时MyBatis才会认为两次查询是“相同的”从而命中一级缓存。那么这个“私人备忘录”什么时候会失效、被清空呢理解这一点至关重要执行了增、删、改操作INSERT, UPDATE, DELETE这是最常见也最容易被忽略的失效条件。只要在同一个SqlSession中执行了任何写操作无论这个写操作是否影响到你缓存的数据整个一级缓存都会被清空。这是MyBatis为了保证数据强一致性而采取的保守策略。例如你先查询了用户A的信息然后修改了用户B的信息此时再查询用户A缓存已经失效会重新查库。手动调用sqlSession.clearCache()方法这是显式清空缓存的方式。对SqlSession执行了commit()或close()操作提交事务或关闭会话自然意味着当前会话的结束缓存也随之销毁。在Mapper映射文件中配置了flushCachetrue这通常用于特定的查询语句强制每次执行都刷新缓存。2.2 一级缓存的典型陷阱与实战解析很多开发者对一级缓存的认知停留在“同会话同查询不走数据库”的层面这远远不够。下面结合几个真实场景看看它如何“坑人”。场景一循环中的无效查询这就是我们开篇事故的简化版。假设有以下代码try (SqlSession sqlSession sqlSessionFactory.openSession()) { OrderMapper mapper sqlSession.getMapper(OrderMapper.class); for (Long id : idList) { // 开发者以为每次循环都是独立的查询 Order order mapper.selectOrderById(id); // ... 处理order } }如果idList包含100个不同的ID这段代码会执行100次数据库查询吗会的。因为每次查询的CacheKey中的参数值id都不同所以无法命中缓存。一级缓存在这里没有起到任何优化作用。正确的优化应该是在业务逻辑层做聚合查询或者使用二级缓存。场景二写操作引发的“幽灵”失效try (SqlSession sqlSession sqlSessionFactory.openSession()) { UserMapper mapper sqlSession.getMapper(UserMapper.class); // 第一次查询缓存结果 User user1 mapper.selectUserById(1L); System.out.println(user1.getName()); // 输出: 张三 // 执行一个无关的更新操作 mapper.updateUserStatus(2L, inactive); // 更新了ID2的用户 // 第二次查询参数完全相同 User user2 mapper.selectUserById(1L); System.out.println(user2.getName()); // 输出: 张三但这次真的又访问了数据库 // 因为update操作清空了整个一级缓存 }这个例子清晰地展示了MyBatis一级缓存“宁可错杀不可放过”的失效策略。即使你更新的是ID2的用户ID1的用户的缓存也被清除了。这在一些复杂的业务逻辑中可能导致性能波动难以定位。场景三Spring集成下的特殊表现在Spring MyBatis的经典组合中我们通常使用Transactional注解来管理事务。Spring默认将SqlSession的生命周期与事务绑定。这意味着在同一个Transactional方法内部多次调用同一个查询是可以命中一级缓存的。但是一旦方法执行完毕事务提交SqlSession就被关闭缓存也随之销毁。因此跨方法的调用即使是在同一个Service类中如果不在同一个事务上下文中就无法利用一级缓存。实操心得一级缓存更像是一个“会话内”的临时加速器它的作用域太小失效又太“激进”。对于大多数需要性能优化的场景我们不能依赖它。它的主要价值在于避免在同一个事务方法内对完全相同的数据进行重复查询。在代码审查时要特别警惕在循环内进行单条查询的模式这通常是一级缓存无法优化的性能瓶颈点。3. 二级缓存Namespace级别的“团队共享白板”如果一级缓存是私人备忘录那么二级缓存就是挂在团队办公室里的“共享白板”。它的作用域是一个Mapper的namespace所有属于这个namespace的SqlSession都可以读取和写入这块白板。3.1 二级缓存的启用与核心配置二级缓存默认是关闭的需要显式开启。配置分为两步第一步在MyBatis全局配置文件mybatis-config.xml中开启缓存通常默认就是开启的。settings !-- 默认就是true通常不需要显式配置 -- setting namecacheEnabled valuetrue/ /settings第二步在需要启用二级缓存的Mapper XML文件中添加cache/标签。?xml version1.0 encodingUTF-8? !DOCTYPE mapper PUBLIC -//mybatis.org//DTD Mapper 3.0//EN http://mybatis.org/dtd/mybatis-3-mapper.dtd mapper namespacecom.example.mapper.UserMapper !-- 声明启用本Mapper的二级缓存 -- cache/ select idselectUserById resultTypeUser select * from user where id #{id} /select !-- ... 其他语句 -- /mapper一个简单的cache/标签会使用MyBatis默认的缓存实现一个基于内存的LRU缓存。你可以通过标签属性进行详细配置cache evictionLRU !-- 回收策略LRU最近最少使用、FIFO先进先出、SOFT软引用、WEAK弱引用 -- flushInterval60000 !-- 刷新间隔毫秒。不设置则不清空 -- size1024 !-- 最多缓存对象个数 -- readOnlytrue/ !-- 是否只读。只读缓存性能更高但返回的是缓存对象的引用修改它会影响缓存中的数据 --重要提示readOnlytrue时MyBatis会直接返回缓存对象的引用性能最好但要求缓存的对象必须是可序列化的并且调用方不能修改返回的对象。readOnlyfalse时MyBatis会返回缓存对象的深拷贝通过序列化/反序列化安全但性能有损耗。3.2 二级缓存的工作机制与数据同步问题二级缓存的工作流程比一级缓存复杂当一个SqlSession执行查询后在关闭或提交时它才会决定是否将查询结果提交到二级缓存。另一个SqlSession执行查询时会先尝试从二级缓存中获取。任何一个SqlSession执行了INSERT、UPDATE、DELETE操作并提交后MyBatis会清空整个对应Mapper namespace的二级缓存。这里就引出了二级缓存最核心、也最让人头疼的问题数据一致性问题。问题一跨命名空间的缓存污染假设有两个MapperUserMapper和OrderMapper。Order对象中关联了一个User对象通过userId。你在OrderMapper.xml中配置了cache/并写了一个联表查询selectOrderWithUser。!-- OrderMapper.xml -- cache/ select idselectOrderWithUser resultMaporderWithUserMap select o.*, u.name as user_name from orders o left join user u on o.user_id u.id where o.id #{id} /select当你查询一个订单时用户信息也会被缓存到OrderMapper的二级缓存中。此时如果另一个程序直接通过UserMapper更新了该用户的名字OrderMapper的缓存是感知不到的它里面存储的还是旧的用户名。这就导致了数据不一致。解决方案通过cache-ref标签建立缓存引用关系。!-- OrderMapper.xml -- cache-ref namespacecom.example.mapper.UserMapper/这样OrderMapper就不会维护自己的缓存而是共享UserMapper的缓存空间。当UserMapper的缓存因更新而清空时OrderMapper查询到的关联用户信息也会失效。但这种方式增加了耦合需谨慎使用。问题二多表操作与缓存清空粒度正如一级缓存二级缓存在执行写操作时清空的也是整个namespace的缓存。如果你有一个UserMapper里面既有selectUserById也有selectAllUsers。当你更新了一个用户后所有用户的缓存包括那个列表查询的缓存都会被清空。这可能不是你想要的特别是当列表查询非常耗时的时候。解决方案更精细的缓存控制。你可以在单个语句上设置useCache和flushCache属性。select idselectAllUsers resultTypeUser useCachefalse select * from user /select将非常耗时的、或者实时性要求不高的列表查询设置为useCachefalse不让它进入二级缓存。或者对于某些希望实时性的查询设置flushCachetrue确保每次执行都刷新缓存并获取最新数据。3.3 二级缓存的适用场景与避坑指南二级缓存并非银弹它有非常明确的适用边界适合的场景只读或极少修改的数据例如国家省份字典表、配置信息表、历史归档数据等。对实时性要求不高的统计类查询例如每日报表、历史趋势分析。单体应用且数据访问模式相对简单没有复杂的多表关联更新。需要规避或谨慎使用的场景多表关联且关联表会被频繁更新的查询如上文所述极易出现数据不一致。在分布式部署环境下默认的基于内存的二级缓存是应用内缓存多个应用实例之间无法同步。实例A更新了数据清空了自己的缓存但实例B的缓存里还是旧数据。对数据强一致性要求极高的业务如金融交易核心数据。实操心得我的建议是在中小型单体应用中可以针对性地为少数真正的只读数据开启二级缓存并仔细评估其关联关系。在微服务或分布式架构中默认关闭所有二级缓存将缓存的需求上移到业务层使用Redis等分布式缓存中间件来统一管理这样可控性、一致性和扩展性都更强。不要因为“可能有性能提升”就盲目开启二级缓存它带来的数据一致性问题往往比性能提升更棘手。4. 整合外部缓存“三级缓存”走向分布式与专业化当二级缓存无法满足分布式环境下的数据共享和容量需求时我们就需要引入“三级缓存”——即外部的专业缓存中间件如Redis、Memcached、Ehcache集群模式等。MyBatis本身提供了一个Cache接口允许我们方便地集成这些实现。4.1 为何需要外部缓存分布式共享这是最主要的原因。在集群部署中多个应用实例需要共享同一份缓存数据避免每个实例都缓存一份导致数据不一致和内存浪费。容量与持久化应用内存有限而Redis等中间件可以提供GB甚至TB级别的缓存容量并且支持持久化防止应用重启后缓存雪崩。丰富的特性外部缓存提供了更丰富的功能如设置不同的过期时间TTL、发布订阅、复杂数据结构支持、高可用集群等。专业化管理缓存中间件有专业的监控、管理和运维工具便于排查问题。4.2 如何集成Redis作为MyBatis二级缓存这里以集成Redis为例展示一种常见的实现方式。我们通常不直接替换MyBatis默认的二级缓存而是通过实现org.apache.ibatis.cache.Cache接口创建一个RedisCache。第一步添加依赖以Spring Boot为例dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependency第二步实现Cache接口import org.apache.ibatis.cache.Cache; import org.springframework.data.redis.core.RedisTemplate; import org.springframework.data.redis.serializer.StringRedisSerializer; import java.util.concurrent.TimeUnit; import java.util.concurrent.locks.ReadWriteLock; import java.util.concurrent.locks.ReentrantReadWriteLock; public class RedisCache implements Cache { private final ReadWriteLock readWriteLock new ReentrantReadWriteLock(); private final String id; // Mapper的namespace private static RedisTemplateString, Object redisTemplate; // 需要静态注入 public RedisCache(String id) { if (id null) { throw new IllegalArgumentException(Cache instances require an ID); } this.id id; } // 静态方法用于在应用启动时注入RedisTemplate public static void setRedisTemplate(RedisTemplateString, Object redisTemplate) { RedisCache.redisTemplate redisTemplate; // 建议设置key和value的序列化器这里示例使用String序列化keyJackson序列化value redisTemplate.setKeySerializer(new StringRedisSerializer()); // 设置ValueSerializer例如使用GenericJackson2JsonRedisSerializer } Override public String getId() { return this.id; } Override public void putObject(Object key, Object value) { if (redisTemplate ! null value ! null) { // 将CacheKey转换为String作为Redis的key String redisKey id : key.toString(); // 存入Redis可以设置过期时间例如30分钟 redisTemplate.opsForValue().set(redisKey, value, 30, TimeUnit.MINUTES); } } Override public Object getObject(Object key) { if (redisTemplate ! null) { String redisKey id : key.toString(); return redisTemplate.opsForValue().get(redisKey); } return null; } Override public Object removeObject(Object key) { if (redisTemplate ! null) { String redisKey id : key.toString(); Object oldValue redisTemplate.opsForValue().get(redisKey); redisTemplate.delete(redisKey); return oldValue; } return null; } Override public void clear() { // 清空整个namespace的缓存可以使用通配符删除 if (redisTemplate ! null) { SetString keys redisTemplate.keys(id :*); if (keys ! null !keys.isEmpty()) { redisTemplate.delete(keys); } } } Override public int getSize() { Long size 0L; if (redisTemplate ! null) { SetString keys redisTemplate.keys(id :*); size keys ! null ? (long) keys.size() : 0L; } return size.intValue(); } Override public ReadWriteLock getReadWriteLock() { // 在分布式缓存中读写锁通常意义不大返回一个空实现或简单的锁即可 return this.readWriteLock; } }第三步在应用启动时配置RedisTemplate并注入到Cache实现中Configuration public class MyBatisRedisCacheConfig { Bean public RedisTemplateString, Object redisTemplate(RedisConnectionFactory factory) { RedisTemplateString, Object template new RedisTemplate(); template.setConnectionFactory(factory); template.setKeySerializer(new StringRedisSerializer()); template.setValueSerializer(new GenericJackson2JsonRedisSerializer()); template.afterPropertiesSet(); // 注入到我们的RedisCache类中 RedisCache.setRedisTemplate(template); return template; } }第四步在Mapper XML中指定使用自定义的Cache实现mapper namespacecom.example.mapper.UserMapper !-- 使用自定义的Redis缓存 -- cache typecom.example.cache.RedisCache/ !-- 后续的SQL语句 -- /mapper4.3 使用外部缓存的注意事项与优化序列化与反序列化开销对象需要在Java内存和Redis存储间序列化/反序列化这会带来CPU开销和延迟。要选择高效的序列化方案如Kryo、Protobuf或Jackson的Smile格式并评估缓存对象的大小和复杂度。缓存Key的设计上面的示例简单使用了CacheKey的toString()这可能产生很长且不易读的Key。在生产环境中最好能设计一个更简洁、可读的Key生成策略便于监控和排查。过期策略与内存管理一定要为缓存设置合理的TTL生存时间防止冷数据常驻内存。同时要监控Redis的内存使用情况避免缓存击穿或雪崩。缓存穿透、击穿、雪崩这是使用任何分布式缓存都要面对的经典问题。需要在业务代码或缓存中间件层面考虑解决方案如布隆过滤器、互斥锁、随机过期时间等。事务一致性MyBatis的缓存清空机制在写操作后清空对应namespace缓存在分布式环境下依然有效但清空的是Redis中的对应键。你需要确保Redis操作和数据库事务的最终一致性这通常比本地缓存更复杂。实操心得将MyBatis缓存扩展到Redis实际上是将缓存的管理职责从ORM框架部分转移到了专门的缓存基础设施。这带来了更大的灵活性和更强的能力同时也引入了新的复杂度。我个人的做法是在业务层Service层显式地使用Redis缓存而不是在MyBatis Mapper层做透明集成。这样缓存的读、写、失效逻辑完全由业务代码控制意图更清晰更容易处理复杂的数据一致性问题也便于做更精细的监控和治理。MyBatis自带的二级缓存机制在这种架构下通常会被选择关闭。5. 缓存策略的深度思考与生产实践建议经过对三级缓存的层层剖析我们最后需要跳出具体的技术细节从更高维度思考在实际项目中我们到底该如何制定缓存策略5.1 不同层级缓存的定位与选择我们可以把数据访问的路径想象成一条有多个检查站的公路一级缓存SqlSession是第一个、也是最快速的检查站但它只对当前这辆车当前会话本次行程有效。它的作用是消除同一事务上下文内的绝对重复查询。二级缓存Namespace是第二个检查站所有走这条公路访问这个Mapper的车都能共享信息。但它建在路边应用内存其他平行的公路其他应用实例看不到。适合缓存全局性、极少变更的只读数据。外部缓存如Redis是一个建在云端的中央情报站所有公路上的车都能实时同步信息。它能力强大但访问它需要一点时间网络IO。适合作为业务层缓存存储经过加工的热点数据支撑高并发场景。选择建议默认策略在大多数Spring Boot项目中结合MyBatis-Plus或默认配置可以完全依赖一级缓存来处理会话内重复查询而显式关闭所有XML中的二级缓存cache enabledfalse/。将缓存的重任交给业务层和Redis。何时启用二级缓存仅当你能百分百确定某个Mapper对应的表是“静态表”如数据字典且几乎没有其他表与之关联更新时可以谨慎开启。并务必设置合理的flushInterval和size。何时使用外部缓存当你的应用需要部署多个实例或者需要缓存的数据量很大、结构复杂或者需要对缓存有更精细的控制如不同键不同TTL时就必须引入Redis等分布式缓存。此时MyBatis的二级缓存应被禁用。5.2 缓存模式与失效策略的设计在业务层使用缓存特别是Redis时有几种常见模式Cache-Aside旁路缓存这是最常用的模式。应用代码直接管理缓存。读流程先读缓存命中则返回未命中则读数据库并将结果写入缓存。写流程先更新数据库然后删除缓存而非更新缓存。这是为了避免在并发写时出现更新顺序问题导致脏缓存。// 伪代码示例Cache-Aside模式 public User getUserById(Long id) { String key user: id; // 1. 读缓存 User user redis.get(key); if (user ! null) { return user; } // 2. 缓存未命中读数据库 user userMapper.selectById(id); if (user ! null) { // 3. 写入缓存设置过期时间 redis.setex(key, 300, user); // 过期时间5分钟 } return user; } public void updateUser(User user) { // 1. 更新数据库 userMapper.updateById(user); // 2. 删除缓存 redis.delete(user: user.getId()); }Write-Through直写任何对数据库的写操作都同步更新缓存。这对缓存的一致性保障最好但每次写操作都有额外的缓存更新开销通常需要缓存组件本身提供这种支持。Write-Behind后写先更新缓存然后异步批量更新数据库。性能最高但存在数据丢失风险缓存宕机。在生产环境中Cache-Aside 删除失效是最为稳健和灵活的策略。对于“删除缓存”这一步在超高并发场景下还需要考虑“先删缓存再更新数据库”可能引发的并发问题如经典的“读写并发导致旧缓存回填”问题有时会采用“延迟双删”等更复杂的策略来保证最终一致性。5.3 监控、排查与性能调优引入了缓存就必须配套完善的监控体系。监控指标缓存命中率Hit Ratio这是最重要的指标。命中率过低如低于80%说明缓存策略可能有问题或者缓存的数据不是热点。缓存容量与内存使用率防止Redis被撑满。缓存操作耗时特别是网络往返时间RTT。数据库QPS观察引入缓存后数据库压力的下降是否达到预期。常见问题排查思路缓存穿透大量请求查询一个不存在的数据如不存在的用户ID。解决方案对不存在的数据也进行短时间缓存如缓存null值设置很短TTL或者使用布隆过滤器Bloom Filter在查询前进行拦截。缓存击穿某个热点Key过期瞬间大量请求同时到达数据库。解决方案使用互斥锁Mutex Lock只让一个请求去加载数据其他请求等待。或者在业务允许的情况下设置热点数据永不过期由后台任务异步更新。缓存雪崩大量Key在同一时间点过期导致所有请求涌向数据库。解决方案为缓存Key的过期时间设置一个随机波动值例如基础TTL随机分钟数避免同时失效。MyBatis缓存调试在开发阶段可以开启MyBatis的日志级别来观察缓存行为。将org.apache.ibatis.cache包的日志级别设为DEBUG可以看到缓存命中、未命中和清空的具体日志对于理解缓存行为非常有帮助。缓存是提升系统性能的利器但也是一把双刃剑。它通过引入额外的复杂度一致性、维护成本来换取性能的提升。没有一个放之四海而皆准的缓存方案。最关键的是深入理解你的业务数据访问模式哪些是热点数据数据的更新频率如何一致性要求有多高只有回答了这些问题你才能设计出最适合当前场景的、优雅的缓存方案。从MyBatis内置的轻量级缓存到强大的分布式Redis缓存工具就在那里而如何用好它们才是对我们开发者真正的考验。
)
