缓存击穿是热点key失效瞬间大量请求穿透缓存直击MySQL，并非MySQL自身问题，而是应用层未做兜底防护；需通过Redis互斥锁（SETNX+EX）或空值缓存等策略在应用层解决。
MySQL 重复查询引发的缓存击穿到底是什么
缓存击穿不是 MySQL 自己的问题，而是你用缓存时没兜住「热点 key 失效瞬间的并发穿透」。典型场景：某个 user_id=123 的记录被缓存在 Redis 里，TTL 到期后同时有 50 个请求查不到缓存，全打到 MySQL，瞬间压垮数据库连接或慢查询堆积。
MySQL 本身不提供「本地缓存」或「自动防击穿」机制，它只负责执行 SQL。所谓「解决」，其实是你在应用层加策略——要么在 MySQL 前加一层带保护的缓存，要么让应用自己控制查询节奏。
用 Redis + SETNX 实现简单防击穿（推荐新手起步）
不用改 MySQL 配置，也不依赖复杂中间件，靠 Redis 的原子操作就能拦住大部分击穿流量。核心是：失效时不直接删 key，而是设一个短 TTL 的空值 or 用互斥锁预热。
- 错误做法：
DEL user:123后立刻放行所有请求 → 全部击穿 - 正确做法：失效前先用
SET user:123_lock "1" NX EX 30占坑，只有拿到锁的请求去查 MySQL 并写回缓存，其余请求等几秒再重试 - 注意
NX和EX必须一起用，单独SETNX没过期时间，锁可能永远不释放 - 如果业务允许短暂 stale 数据，更轻量的做法是：查不到缓存时，
SET user:123 "" EX 5（空值兜底），避免后续请求继续穿透
本地缓存（Caffeine / Guava）适合什么场景
本地缓存不是用来抗大流量的，而是帮你省掉「本机到 Redis 的网络开销」和「序列化成本」。它和 MySQL 缓存击穿的关系很弱，但能缓解某些特定压力点。
- 适用：读多写少、数据变更不频繁、单机部署、对一致性要求不高（比如配置类、地区字典）
- 不适用：用户会话、订单状态、库存余额等强一致场景 —— 本地缓存无法跨实例同步，容易脏读
-
Caffeine.newBuilder().maximumSize(1000).expireAfterWrite(10, TimeUnit.MINUTES)是常用配置，别盲目调大maximumSize，堆内存爆了比击穿还难查 - 如果用了本地缓存又连 Redis，记得加二级缓存逻辑：先查本地 → 没有再查 Redis → 还没有才查 MySQL，并把结果写回两级
为什么不能靠 MySQL Query Cache 或 InnoDB Buffer Pool 解决击穿
这两个是 MySQL 内置机制，但它们和「应用层缓存击穿」完全不是一回事，强行混用反而误导排查方向。
-
query_cache_type=1在 MySQL 8.0 已被移除，5.7 默认关闭，且只缓存完全相同的 SELECT 字符串（大小写、空格、注释都影响命中），实际几乎不可控 - InnoDB Buffer Pool 缓的是页（page），不是业务记录；即使
SELECT * FROM users WHERE id=123被反复执行，Buffer Pool 也只是减少磁盘 IO，不减少解析、优化、锁竞争等开销 - Buffer Pool 大小由
innodb_buffer_pool_size控制，设太大挤占系统内存，太小导致频繁刷页 —— 和缓存击穿无直接关系
真正要盯住的，是你代码里那句 redis.get("user:" + userId) 后有没有 fallback 保护，以及 Redis key 的过期策略是否和业务生命周期匹配。击穿从来不在数据库里发生，而在你忘记加锁或兜底的那一行代码上。
