Redis慢查询日志仅记录命令在主线程中实际执行的CPU耗时，不包含网络往返、命令排队及响应传输等外部延迟；其核心配置为slowlog-log-slower-than（默认10ms）和slowlog-max-len（默认128），通过SLOWLOG GET可查看详细日志。
slowlog 只记录命令执行时间，不包含排队和网络耗时
Redis 的 SLOWLOG 本质是记录「主线程实际执行命令所花的 CPU 时间」，比如 HGETALL 扫描一个含 10 万字段的哈希表，耗时 80ms，就会被记入日志；但这个 80ms 不包括：客户端发包到 Redis 的网络往返、命令在队列里排队等待执行的时间、响应返回给客户端的网络延迟。所以看到 SLOWLOG GET 里某条记录耗时 50ms，不能直接等同于用户感知的“慢”。
用 redis-cli --latency 测网络往返，--intrinsic-latency 测服务器固有延迟
区分延迟来源的关键是分层测量：
-
redis-cli --latency -h <host> -p <port></port></host>：在客户端机器上运行，测的是 PING 命令从发出到收到 reply 的完整 RTT（含网络传输、TCP 栈、Redis 处理），结果如min:0, max:3, avg:0.22（单位 ms）——如果这个值明显高于基线（比如 >2ms），说明网络或客户端环境有问题 -
redis-cli --intrinsic-latency 60：必须在 Redis 服务器本机运行，它绕过网络，只测 Redis 进程自身调度和内存访问延迟。若这里出现 500μs 以上尖峰，说明服务器存在 CPU 抢占、中断风暴或 NUMA 问题 - 两者差值（比如
--latency平均 1.8ms，--intrinsic-latency最大 0.05ms）基本就是网络+客户端开销
结合 INFO 中的 blocked_clients 和 instantaneous_ops_per_sec 判断排队延时
当慢查询真实存在时，Redis 单线程会阻塞后续请求，导致请求堆积。这时仅看 SLOWLOG 不够，要查实时状态：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
blocked_clients非 0：说明有客户端卡在BLPOP/BRPOP等阻塞命令上，不是性能问题，是业务逻辑等待 -
instantaneous_ops_per_sec持续低于预期（比如平时 2w QPS，现在只有 2k），同时SLOWLOG LEN突增，大概率是慢命令拖垮了吞吐 -
used_memory_rss / used_memory即mem_fragmentation_ratio> 1.5：内存碎片高会导致 malloc 变慢，间接拉长命令执行时间，这种“慢”不会出现在SLOWLOG里，但会抬高--intrinsic-latency测出的毛刺
MONITOR 输出能暴露排队现象，但别在生产长期开
redis-cli MONITOR 实时打印每条命令到达和返回的时间戳（格式如 +1720872543.123456[0] "GET" "key"），如果你在客户端发起请求后，发现命令在 MONITOR 里“出现”和“结束”之间间隔远大于 SLOWLOG 记录的执行时间，就说明中间有排队——比如命令 A 耗时 3ms，但命令 B 在它之后 120ms 才开始执行，那这 117ms 就是排队等待时间。
真正难的是把网络、排队、执行三段延迟归因到具体环节。多数人漏掉的是：没在服务端跑 --intrinsic-latency，也没对比客户端 --latency 和服务端 SLOWLOG 的数量级关系。这两个动作不做，光看 SLOWLOG 就容易误判。
