SQL 查询缓存失效主因是策略不当与数据变更，非并发过高；常见触发点包括表结构变更、DML 操作、不确定函数等；高并发下易引发雪崩、穿透、击穿叠加；应采用随机过期、逻辑过期、空值缓存、布隆过滤器及分级缓存等策略应对。
SQL 数据库查询缓存失效在高并发场景下常被误认为是“缓存没起作用”，其实多数情况并非缓存本身坏了，而是缓存策略、数据变更频率和 并发访问 模式共同导致命中率骤降。关键在于理解缓存失效的触发条件，而非单纯加大缓存容量。
查询缓存失效的常见触发点
MySQL 5.7 及之前版本的 Query Cache（已从 8.0 移除）或应用层缓存（如 Redis 中存 SELECT 结果）都会因以下操作立即失效：
- 表结构变更（ALTER TABLE、DROP INDEX 等）——整张表对应的所有缓存条目清空
- 任意 DML 操作（INSERT/UPDATE/DELETE）影响该表——即使只改一行，所有查这张表的缓存全失效
- 使用了不确定函数（NOW()、RAND()、USER()等）的查询——每次执行视为不同 SQL，无法复用缓存
- 查询中包含用户变量、临时表、存储过程调用——Query Cache 默认不缓存这类语句
高并发下缓存雪崩与穿透的叠加效应
当 热点 数据（如商品详情、用户配置）缓存失效时，并发请求 会同时击穿到数据库：
- 缓存雪崩：多个关联查询缓存集中在同一秒过期，数据库瞬间承受数倍 QPS 压力
- 缓存穿透：恶意或错误请求查大量不存在的 ID（如 user_id = -1 或超大随机数），缓存不存空值，每次直连 DB
- 缓存击穿：单个热门 key（如秒杀商品库存）过期瞬间，数十万请求争抢重建缓存，DB 连接池迅速耗尽
这三类问题在高并发中往往交织发生，比如一个 UPDATE 触发缓存批量失效，紧接着大量请求因未命中而涌向 DB，其中夹杂部分非法 ID 请求，进一步拖慢响应。
缓解缓存失效影响的实用策略
不依赖“永不失效”的缓存，而是设计具备弹性和兜底能力的缓存链路：
- 设置随机过期时间：避免集中失效，例如基础 TTL 为 300 秒，再加±60 秒随机偏移
- 主动刷新 + 逻辑过期：缓存值内嵌一个逻辑过期时间字段，后台异步更新；过期后不删除，仅标记为“待更新”，新请求触发 异步加载，旧值继续可用
- 空值缓存与布隆过滤器：对确定不存在的查询（如无效订单号），缓存空对象（带短 TTL），并在接入层前置布隆过滤器拦截明显非法 ID
- 读写分离 + 缓存分级：高频只读场景用 LocalCache（Caffeine）抗瞬时流量，配合分布式缓存（Redis）做一致性兜底；写操作后仅失效本地缓存，通过消息队列异步通知其他节点刷新
验证缓存是否真失效？别只看命中率
高并发下命中率低≠缓存失效机制有问题，更可能是查询本身不具备可缓存性：
- 检查 SQL 是否含动态参数（如 WHERE user_id = ?）、隐式类型转换（字符串 ID 被传为数字）、或未统一大小写 / 空格格式——这些都会导致缓存键不同
- 用 Redis Monitor 或 MySQL general_log 观察实际执行的 SQL 文本，对比缓存 Key 生成逻辑
- 在应用层打点统计：记录每次查询前是否命中缓存、缓存是否存在、是否因空值跳过缓存等，定位是“没缓存”还是“缓存了但没用上”
很多所谓“缓存失效”问题，根源是查询构造不规范或缓存 Key 设计太粗糙，而不是并发太高。
