清空全站缓存会瞬间触发大量缓存重建请求，全部落到数据库导致磁盘读i/o暴增；需通过iostat观察rmb/s飙升、r_await骤升、%util近100%但cpu低等特征确认，并用iotop和show processlist定位回源进程与慢查询。
清空全站缓存本身不耗CPU、不占内存，但会瞬间触发大量缓存重建请求——这些请求几乎全部落到数据库上，造成磁盘读I/O暴增。这不是“缓存没清好”，而是缓存策略与下游承载能力没对齐。排查重点不在缓存系统本身，而在它引发的连锁读压。
看I/O特征：确认是不是缓存重建惹的祸
先用 iostat -x 1 5 观察核心指标：
- rMB/s 突然飙升，wMB/s 基本不变 → 典型读密集型重建，不是写日志或备份在捣鬼
- await（尤其是 r_await）从 0.3ms 涨到 40ms+，且 aqu-sz > 5 → 请求排队严重，磁盘在硬扛
- %util 接近 100%，但 CPU 使用率仍低于 40% → CPU 在等数据，不是算力瓶颈
查源头进程：定位哪个服务在疯狂回源
运行 sudo iotop -o，重点关注：
- 哪几个应用进程的 READ 列数值最高（单位 MB/s）
- 这些进程是否对应缓存代理（如 Nginx 的 proxy_cache_revalidate）、API网关或业务服务（如商品详情服务）
- 结合时间点比对：是否与缓存清空操作（如执行了 redis-cli FLUSHALL 或 CDN purge）严格吻合
下钻SQL层：找到被高频击穿的查询
一旦确认是应用层在回源，立刻连上数据库：
- MySQL：执行 SHOW PROCESSLIST，筛选 State = "Sending data" 或长时间 Waiting for table metadata lock 的语句
- 查慢日志或 Performance Schema：SELECT * FROM performance_schema.events_statements_summary_by_digest ORDER BY SUM_TIMER_WAIT DESC LIMIT 5，找平均响应时间最长、执行次数最多的 SELECT
- 重点盯那些没走索引、rows_examined 远大于 rows_sent 的查询——它们就是缓存失效后被反复扫描的“元凶”
验证与收敛：快速止血+长期加固
应急时可临时限流或降级缓存重建逻辑；长期要打破“全量重建=全量扫库”的惯性：
- 避免“一清全清”：按业务域分片清理（如只清商品缓存，不动用户缓存）
- 加重建保护：对高频热点key，设置 逻辑过期 + 后台异步刷新，而不是等待请求触发同步回源
- 给回源SQL兜底：为关键查询添加强制索引提示、限制最大返回行数、预热常用WHERE条件组合
