SQL缓存一致性需应用层主动设计，推荐写后失效策略（先更新DB再删缓存），避免先删缓存后更新DB；读多写少场景宜用懒加载，高一致性需求可预热缓存；并发下可用分布式锁、版本号或MQ保障顺序；需建立比对、告警、手动刷新等兜底机制。
SQL缓存一致性不是靠数据库自动解决的，而是由应用层结合缓存策略主动设计和控制的。核心矛盾在于：数据库改了，缓存没同步，用户就可能读到旧数据；而盲目删缓存或强刷缓存，又可能引发性能抖动或并发问题。关键是要在「及时性」和「可用性」之间找平衡。
缓存失效策略：什么时候删缓存？
最常用、也最稳妥的做法是「写后失效（Cache-Aside + Delete on Write）」：先更新数据库，再删除对应缓存key，下次读请求自然触发回源加载新数据。
- ✅ 推荐用于大多数业务场景（如商品信息、用户资料）
- ⚠️ 注意：删除失败需有补偿机制（如异步重试、日志告警），否则缓存永久脏化
- ❌ 避免「先删缓存再更新DB」——中间若DB更新失败，缓存空了，后续读会误加载旧值（因为旧数据还在DB里）
缓存更新策略：什么时候写缓存？
不建议直接「写缓存+写DB」双写，极易因网络、顺序、异常导致不一致。更可控的方式是「只删不写」，让读请求按需重建缓存（Lazy Load）。
- ✅ 读多写少场景下，延迟加载天然降低写压力，且避免无效缓存堆积
- ⚠️ 若对首次读延迟敏感（如首页强一致性），可搭配「更新DB后主动预热缓存」（但要确保预热逻辑幂等）
- ❌ 不要依赖定时任务批量刷缓存——无法感知实时变更，滞后高，还可能刷错版本
应对并发写：防止缓存与DB错乱
当多个线程/服务同时修改同一条记录时，删缓存和更新DB的顺序可能被交叉执行，导致脏数据残留。常见防御手段：
- 加分布式锁（如Redis SETNX）控制同一key的写操作串行化，适合变更频次不高、key粒度适中的场景
- 引入版本号或时间戳字段，在更新DB和删缓存时一并校验，丢弃过期写请求
- 使用「更新DB + 发送MQ消息」解耦，由消费者统一处理缓存删除，天然具备重试和顺序保障能力
兜底方案：如何发现并修复不一致？
再严谨的设计也无法100%杜绝异常。需要建立可观测性和自愈能力：
- 对核心缓存key做定期比对（如抽样查DB和Redis的值是否一致），发现问题自动告警
- 提供运营后台的「强制刷新缓存」按钮，支持人工干预
- 在关键读接口增加「一致性校验开关」，开启时主动比对缓存与DB，不一致则自动更新缓存并上报
不复杂但容易忽略。真正决定一致性的，从来不是缓存工具本身，而是你对数据流的理解和对异常路径的敬畏。
