缓存击穿不会导致单条命令duration显著升高，而是表现为同一key的get/set/del在毫秒级窗口内密集出现，需结合slowlog模式、keyspace_misses激增及db延迟飙升交叉验证。
击穿本身不会直接产生“慢查询”，SLOWLOG GET 里看到的通常不是单条超长耗时命令，而是同一 key 的 GET/SET/DEL 在毫秒级窗口内密集出现——这才是你要盯的模式。
为什么击穿不会在Slowlog里显示高duration
缓存击穿的本质是大量并发请求在 key 过期后同时穿透到 DB，再由应用层争抢重建缓存。Redis 层面的 GET 命令本身很快（200–800μs），SET 也快，所以每条记录的 duration 字段往往不超标；真正卡住的是应用逻辑（查 DB、序列化、加锁、写缓存）和数据库侧压力。
-
duration只统计 Redis 内部执行时间，不含网络往返、客户端处理、DB 查询等环节 - 击穿发生时，
SLOWLOG GET中高频出现的是同一业务 key 的GET+DEL+SET组合，而非某一条命令耗时突增 - 若你发现某
key的GET耗时突然从 300μs 跳到 5ms+，更可能是该 key 是BigKey或所在 slot 正在迁移，而非击穿
怎么从SLOWLOG GET输出识别击穿链路
重点不是看单条 duration 多高，而是看 command 序列是否呈现“读-删-写”密集闭环，且集中在同一 key 上。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 执行
SLOWLOG GET 100（别用SLOWLOG GET不带参数，可能阻塞） - 逐条检查
command字段：找重复出现的业务前缀 key，如item:12345、user:9988 - 确认时间戳字段是否集中在几秒内（比如 5 秒内出现 20+ 条
GET item:12345，紧跟着 3 条DEL item:12345和 5 条SET item:12345） - 配合
INFO stats查keyspace_misses是否在同一时段陡增，再比对应用日志中该 key 的 DB 查询延迟是否同步飙升
slowlog-log-slower-than设多少才抓得住击穿线索
设成 1000μs（1ms）是底线，否则会漏掉大量本可预警的 GET 尖峰。
- 默认 10000μs（10ms）完全无效：击穿时的
GET很少超 10ms，但 1ms 级别的密集访问已足够压垮 DB 连接池 - 设为 0 可记录全部命令，但日志膨胀快，线上慎用；建议先设
1000，观察SLOWLOG LEN是否稳定在 500–800 条 - 记得执行
CONFIG REWRITE持久化配置，否则重启后恢复默认值 - 如果日志里全是
CLIENT SETNAME或PING，说明客户端连接复用差或健康检查太频繁，要先调客户端
仅靠Slowlog不够，必须交叉验证的三个点
Slowlog 是线索入口，不是结论依据。击穿判断必须结合其他信号交叉印证，否则容易把运维误操作（如 SCAN 不带游标）当成业务热点。
- 查
redis-cli --hotkeys输出：若某 key 排名突跃但TTL显示 -1（刚过期），高度可疑；但注意该命令采样不实时，需配合SLOWLOG时间窗口比对 - 看
INFO stats中的expired_keys累计值：如果某分钟内该值增长上千，且与keyspace_misses尖峰重叠，基本锁定是批量过期引发的击穿或雪崩 - 应用层埋点必须覆盖“缓存未命中→DB 查询耗时→缓存写入成功”全链路：如果 DB 查询平均耗时从 15ms 涨到 120ms，而 Redis
GETduration 无变化，那问题就在下游，不是 Redis 慢
真正难的不是从日志里找出那几行 GET 和 SET，而是确认这些命令背后有没有加锁机制、DB 查询是否走了索引、以及那个 key 的 TTL 是不是被硬编码成固定值——这些细节不查代码和 SQL，光看 Slowlog 什么都得不出。
