这个坑值得记一笔。一次版本发布后 Redis 命中率从九成二掉到六成，数据库读 QPS 涨了两倍，实例内存占用反而下降，业务逻辑没有改动。
刚开始盯着「有批量任务在同一时段清掉了大量 key」，折腾了半个多小时，排掉了。
原因不止一个，得分开看。缓存 key 的前缀随版本改了，新老 key 并存；新增字段导致反序列化失败，读不到就回落数据库；过期时间被顺手调短，热数据提前失效。
第一件事是看命中率与 key 总量的变化
redis-cli info stats | grep -E 'keyspace_hits|keyspace_misses'然后抽样比对新老前缀的 key
redis-cli --scan --pattern 'v2:*' | head -5随后确认是否有批量删除在跑
redis-cli info commandstats | grep -E 'del|unlink'等前面都确认过，再统计旧前缀 key 的残留量
redis-cli --scan --pattern 'v1:*' | wc -l改完先别撤，确认这几项。新前缀预热后命中率回到九成，数据库读 QPS 回落，两套 key 在过期后自然收敛成一套。
缓存 key 的命名要当成对外接口看待，改前缀等于全量失效；发布前先双写一段时间，再切换读取。如果同一现象隔几天又出现，说明根因没找到，别当偶发处理。