缓存核心是将高频、低频变更、可容忍延迟的读请求前置到内存处理，关键在选对场景与保障一致性；优先缓存高并发低更新数据、计算开销大结果稳定内容、允许短时陈旧数据及明显热点key。
直接用缓存减轻 MySQL 压力，核心是把高频、低频变更、可容忍一定延迟的读请求，从数据库前置到内存中处理。关键不在“加缓存”，而在“加对地方”和“管住一致性”。
哪些查询适合缓存
不是所有读操作都值得缓存。优先考虑：
-
高并发读 + 低更新频率：比如商品详情页（一天改几次）、用户基本信息（修改不频繁）、配置表（基本静态）
-
计算开销大但结果稳定：复杂联表聚合、带分页的统计报表（如“昨日TOP10销量”），缓存结果比每次查更高效
-
允许短时间数据陈旧：例如首页推荐列表、文章阅读数（差几秒没关系），避免为强一致性牺牲性能
-
明显热点 key：通过慢日志或监控发现某条 SQL 占了 30% 的 QPS，且返回数据固定，就是典型缓存候选
缓存层级与选型建议
单层缓存容易成为瓶颈或单点故障，常见组合更稳妥：
-
本地缓存（如 Caffeine / Guava Cache）：放在应用进程内，响应最快（纳秒级），适合读多写少、数据量小、允许节点间短暂不一致的场景，比如接口限流计数、开关配置
-
分布式缓存（如 Redis）：跨服务共享，支持丰富数据结构和过期策略，是 MySQL 缓存主力。建议用 String 存序列化对象，Hash 存对象字段，ZSet 做排行榜，避免大 value 和全量扫描
-
跳过缓存直连 DB 的兜底路径：当缓存失效或异常时，自动降级查库，再回填缓存，防止雪崩
缓存更新与一致性策略
缓存和 DB 数据不一致是最常见陷阱。没有银弹，按业务容忍度选：
-
Cache Aside（旁路缓存）最常用：读时先查缓存，未命中再查 DB 并写入缓存；写时先更新 DB，再删缓存（不是改缓存）。删除比更新更安全——避免并发写导致脏数据
-
延时双删防脏读：更新 DB 后删一次缓存，休眠几百毫秒（如 500ms），再删一次。应对“读请求在写删之间穿透并重建旧缓存”的竞态
-
设置合理过期时间 + 主动刷新：给缓存加 TTL（如 10 分钟），同时用异步任务定期预热热门 key，降低集中过期压力
-
关键数据用消息队列解耦更新：DB 更新后发 MQ 消息，由消费者负责删/更新缓存，提升写链路稳定性
必须避开的坑
很多性能问题源于缓存误用：
-
缓存空值防穿透：对查不到的 ID（如 user_id = 999999），也缓
存一个空对象或特殊标记，并设较短过期（如 2 分钟），避免恶意请求反复打穿 DB
-
控制 key 粒度别太粗：不要缓存“全部用户列表”，而应缓存“用户ID→用户信息”，否则一次更新要清整个列表，成本高还易不一致
-
避免缓存大对象：单个 value 超 10KB 容易引发 Redis 阻塞或网络抖动，可拆分或只缓存 ID，查时再按需加载
-
监控缓存命中率：长期低于 80% 就该检查是否 key 设计不合理、过期时间太短，或根本没走缓存路径
缓存不是万能加速器，而是权衡的艺术。设计时多问一句：这个数据真的需要缓存吗？缓存失效了业务能接受吗？更新逻辑能否覆盖所有路径？想清楚再动手，比堆参数有用得多。
