sql 缓存失效主因是查询逻辑、数据变动或配置细节触发隐性刷新，而非缓存本身故障；参数未标准化、ddl 变更、事务一致性缺失及缓存粒度错配是四大关键诱因。
SQL 缓存失效往往不是因为缓存“坏了”，而是查询逻辑、数据变动或配置细节触发了隐性刷新。真正影响性能的，常是那些看似无关紧要却频繁击穿缓存的操作。
参数变化导致缓存键不一致
多数数据库（如 MySQL Query Cache，或应用层如 MyBatis、Redis 中基于 SQL 模板的缓存）会将带参数的 SQL 视为不同语句。例如 SELECT * FROM user WHERE id = 1 和 SELECT * FROM user WHERE id = 2 在未做参数化处理时，会被当作两条独立 SQL，各自缓存——这不仅浪费空间，还让缓存命中率骤降。
- 使用预编译语句（PreparedStatement）确保 SQL 文本统一，参数单独传入
- 在 ORM 中启用缓存 key 标准化，如 MyBatis 的
<cache></cache>配合useCache="true"和flushCache="false" - 避免拼接 SQL 字符串，尤其别用字符串 + 变量方式构造 WHERE 条件
表结构或索引变更强制清空关联缓存
当执行 ALTER TABLE、DROP INDEX 等 DDL 操作时，MySQL Query Cache 会自动清空所有涉及该表的缓存条目；即使只是加了个字段，整张表的历史查询结果都会失效。
- 生产环境 DDL 尽量安排在低峰期，并评估对缓存雪崩的影响
- 禁用 Query Cache（已从 MySQL 8.0 移除）或改用更可控的应用级缓存（如 Redis + 逻辑缓存 key）
- 对核心表做变更前，可先用
SELECT COUNT(*) FROM information_schema.TABLES确认是否有活跃缓存依赖
事务隔离与写操作引发的被动失效
缓存本身不感知事务边界。一个 UPDATE 提交后，若缓存未及时失效，后续 READ COMMITTED 或 REPEATABLE READ 下的 SELECT 仍可能读到旧值——这不是缓存“失效”，而是“未更新”，本质是缓存一致性缺失。
- 采用“写穿透”策略：更新 DB 同时主动删除 / 更新对应缓存 key
- 对高一致性要求场景，设置较短 TTL（如 30 秒），辅以版本号或时间戳校验
- 避免“先删缓存再更新 DB”的时序陷阱，推荐“更新 DB 后删缓存”，并增加失败重试机制
缓存粒度与业务语义错配
按整条 SQL 缓存，容易因排序、分页、状态字段微调而失效；按主键缓存单行数据，又难以支撑列表类查询。缓存粒度选错，等于把油门踩在刹车片上。
- 高频变化字段（如 status、view_count）单独缓存，与基础信息分离
- 列表页优先缓存“ID 集合”，再通过管道批量查详情，减少全量结果缓存压力
- 用业务标识构建缓存 key，比如
user:profile:{uid}比SELECT * FROM user WHERE id={uid}更稳定、易管理
