哈哈，老兄弟们又见面了。今天咱不聊什么高大上的架构，就单纯扒拉扒拉 MyBatis 这个老东西的缓存玩意儿。那啥，前两天在生产环境遇到个现象特别有趣——订单状态查询总是返回旧值，可数据库明明Yi经geng新了。排查一通后发现竟然是 MyBatis 的二级缓存在搞鬼！

MyBatis 有两级缓存：一级和二级。先说一级缓存吧，这玩意儿其实就是个 HashMap 放在 SqlSession 里头。每次你用同一个 SqlSession 查询相同的 SQL，它就会从这个 HashMap 里拿数据而不去查库。

// 一级缓存实现类 PerpetualCache
public class PerpetualCache implements Cache {
    private final Map cache = new HashMap<>;
    public Object getObject {
        return cache.get;
    }
    public void putObject {
        cache.put;
    }
}

害，kan起来简单吧？但是这东西有个致命问题——它跟 SqlSession 的生命周期绑定在一起！SqlSession 一关闭，一级缓存就没了。在 Spring 环境下用 SqlSessionTemplate 时每次调用dou会创建新的 SqlSession，所以实际使用中一级缓存经常根本没机会发挥作用。

再来kan二级缓存，这个geng坑爹。默认情况下它是关闭的，要开启需要配置：

二级缓存也是基于 PerpetualCache 的哈希表实现的！但是geng离谱的是——它跨 SqlSession共享！也就是说多个 SqlSession Ke以共享同一个二级缓存实例。

兄弟问得好啊！我刚开始写博客的时候也遇到过这种问题。主要原因有几个： 1. 内容质量太烂 2. 被收录但排名靠后 3. 没有足够外链指向 4. 网站结构不友好 5. 被判定为低质量或垃圾内容 解决方法嘛： - 写高质量、原创内容 - Zuo好SEO优化 - 提高网站速度和体验 - 建立外部链接 - 耐心等待爬虫抓取 当然啦，有时候也是需要点运气的~

这就是Zui让人抓狂的地方！让我给你画个场景： 1. 用户A查询订单状态为"未支付" 2. 用户B同时支付成功并提交事务将状态改为"Yi支付" 3. 用户A 查询...还是kan到"未支付"

为什么会这样？因为二级缓存在节点A上还有旧值啊！即使另一个节点BYi经geng新了数据库。

sequenceDiagram
    NodeA->NodeB: 查询订单状态 
    NodeB->DB: 支付成功并提交 
    NodeA->NodeA: 
查询...仍然命中本地二级缓存 

"怎么办呢？不如把二级缓存在Redis里搞？" 有兄弟这么问过我。 害嘛子！虽然Neng解决部分问题，但MyBatis默认是不会自动刷新其他节点Redis中的数据啊！ 而且MyBatis的TransactionalCacheManager会导致提交前暂时不刷新Redis...短时间内还是可Nengkan到旧值。

# application.yml
mybatis:
  configuration:
    cache-enabled: false
# 全局禁用所有映射文件中的配置
# 在Spring Boot启动类上添加注解
@EnableCaching // 开启Spring Cache支持
@SpringBootApplication // 不要自动配置DataSource避免冲突

然后换成Spring Cache + Redis/Caffeine组合拳：

@Service
public class OrderService {
    @Autowired private OrderMapper orderMapper;
    @Cacheable
    public Order getOrder {
        return orderMapper.selectById;
    }
    @CacheEvict
    @Transactional // 必须保证先修改DB再清理Redis防止脏读窗口期
    public void updateOrderStatus {
        orderMapper.updateStatus;
        // 其他业务逻辑...
        redisTemplate.convertAndSend; // 额外发送通知其他节点清理本地Caffeine等本地热点数据
    }
}

告诉你吧兄弟： 1. MyBatis二极制无法Zuo到真正强一致性分布式环境下根本靠不住！ 2. Spring Cache+Redis组合geng灵活Ke以设置TTL、监控命中率等等功Neng。 3. Zui重要是可控性强啊！自己决定什么时候清理哪些key！

Ru果业务允许的话Ke以采取以下策略： 1）对非核心业务使用geng长TTL 2）核心业务加版本号校验

public Order getOrder {
   CacheKey key = new CacheKey;
   // 添加版本号校验逻辑防止脏读影响太大范围内可接受即可！
   VersionedOrder cachedOrder = redisTemplate.get;
   if == currentDbVersion) {
       return cachedOrder;
   }
   Order dbOrder = orderMapper.selectById;
   VersionedOrder versionedOrder =
     new VersionedOrder);
   redisTemplate.set;
   return dbOrder;
}

这样虽然不Neng完全避免脏读但至少限制了影响范围。

关于生命周期嘛： - 一极制跟随SqlSession走即时清理无需担忧。 - 二极制Ru果必须使用的话请严格限定只Neng单机使用不要分布式部署！

效率方面： 1）尽量避免复杂SQL直接走库而非依赖复杂KEY计算得到hash结果； 2）对高频热点采用双层结构； 3）合理设计KEY格式以减少冲突可Neng性。

Zui后建议大家在选择技术方案之前一定要先想清楚具体需求场景是否真的适合使用Mybatis原生特性！ hen多时候kan似便捷功Neng背后隐藏着geng多陷阱哦~