SQL缓存失效控制的核心是可控、可预期、低延迟地触发更新，而非完全避免失效；主要策略包括主动失效（先更DB再删缓存）、延时双删（应对主从延迟）、更新缓存（Write Through/Refresh Ahead）及版本号校验，通常组合使用。
SQL缓存失效控制的核心，是让缓存数据与数据库真实状态保持同步，避免读到过期或错误的数据。关键不在于“完全避免失效”，而在于“可控、可预期、低延迟地触发更新”。
主动失效（Invalidate）：最常用也最需谨慎
在数据变更（INSERT/UPDATE/DELETE）后，立刻删除对应缓存键。这是响应快、逻辑清晰的方式，但要注意：
- 必须覆盖所有可能影响该缓存的写路径，比如订单表更新要同时清理“用户订单列表”和“订单详情”两个缓存
- 删除失败不能静默忽略，建议记录日志或走降级补偿（如设置较短的TTL兜底）
- 避免“删除缓存 + 更新DB”顺序——若删缓存后DB更新失败，下次读会把旧值重新刷进缓存，造成脏数据；应优先更新DB，再删缓存
延时双删：应对主从延迟导致的脏读
在主库更新后，先删一次缓存；等主从同步基本完成（如延时500ms），再删一次。适用于对一致性要求高、且存在明显主从延迟的场景。
- 第二次删除不是为了“一定删干净”，而是降低从库延迟窗口内缓存被误读的概率
- 延时时间需根据监控数据设定，不宜固定为1s——可结合binlog位点或GTID做更精准判断
- 注意不要因此拖慢写接口响应，建议异步执行第二次删除
更新缓存（Write Through / Refresh Ahead）：适合读多写少+计算成本高
不删缓存，而是直接把新数据写入缓存（Write Through），或在DB更新后立即查新值并回填缓存（Refresh Ahead）。
- Write Through 要求缓存层支持原子写DB+缓存，通常需自研中间件，落地成本高
- Refresh Ahead 更常见：更新DB后，用异步任务查最新结果并set到缓存，避免并发写引发的覆盖问题
- 注意缓存写失败时的重试机制和幂等性，防止重复更新或雪崩式重刷
版本号/时间戳校验：解决并发更新下的覆盖与过期问题
给缓存值附加一个版本号（如DB中update_time或自增version字段），读取时比对，不一致则触发刷新。
- 适合无法精确知道哪些缓存需要失效的场景（例如一张配置表被多个业务模块共用）
- 可结合布隆过滤器或本地缓存做轻量预检，减少无效DB查询
- 版本信息本身也要缓存，并保证其更新与主数据强一致，否则校验失去意义
缓存一致性没有银弹。选哪种方案，取决于你的数据读写比例、延迟容忍度、系统复杂度和运维能力。多数系统采用“主动失效 + 版本校验兜底 + 合理TTL”组合，既保证大部分情况下的强一致，又守住可用性底线。
