不能只查一个节点就判断“高频慢指令”，因为Redis集群中SLOWLOG是实例级命令，各节点日志独立维护且可能被覆盖，慢查询随slot分布、拓扑变更而分散在不同节点。
直接看 SLOWLOG GET 返回结果里第三字段（耗时）高、且出现频次多的命令，但必须逐节点查、不能只连一个节点就下结论。
为什么不能只查一个节点就判断“高频慢指令”
Redis 集群中 SLOWLOG 是实例级命令，CLUSTER SLOWLOG 语法根本不存在。你连到 A 节点执行 SLOWLOG GET 10，看到全是 HGETALL，不代表 B 节点没在跑 KEYS *——它可能正卡在另一个 slot 上，而你根本没去连。
- 每个节点日志独立维护，
slowlog-max-len默认 128 条，容易被覆盖；不主动巡检，关键记录就丢了 - 客户端哈希标签（如
{user}:1001）或跨 slot 操作（如MGET key1 key2）会导致请求分散，慢查询天然分布在多个节点 - 集群拓扑变更（如 reshard、failover）后，slot 分布变了，但旧慢日志还在原节点，新慢查询已跑到新节点上
怎么快速定位真正高频的慢命令
别只盯着 SLOWLOG GET 的命令名，重点比对三个维度：耗时、频次、节点分布。操作建议如下：
Redis 8.2.3
下载
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
- 用脚本批量连所有主节点（从
CLUSTER NODES解析出 ip:port），对每个节点执行SLOWLOG GET 50，把结果按command+duration+node_id归类统计 - 优先关注
duration >= 50000（50ms）且出现 ≥3 次的命令组合，比如LRANGE big_list 0 -1在 3 个不同节点都出现过 - 用
INFO COMMANDSTATS辅证：查cmdstat_lrange:calls=12345,usec=67890123这类字段，看平均耗时（usec/calls）是否异常，避免被单次毛刺干扰 - 注意
SCAN类命令在日志里显示为SCAN，但实际慢因可能是游标遍历了大量无效 key，得结合--bigkeys扫描结果交叉验证
常见误判场景和对应动作
看到 DEL 或 SET 出现在慢日志里，第一反应不是“命令写错了”，而是检查 key 大小和删除方式：
-
DEL big:hash:key耗时高？立刻跑MEMORY USAGE big:hash:key看内存占用，超 1MB 就算大 key；改用UNLINK替代（Redis 4.0+） -
SET慢？不是网络延迟就是分配内存慢，检查是否在写入百 MB 级字符串，或者用了SET ... EXAT导致时间戳计算开销（极少见但存在） -
EVAL耗时长？SLOWLOG只记 Lua 启动时间，实际瓶颈在脚本内部；得进脚本加redis.log(redis.LOG_WARNING, ...)打点，不能只看命令名 - 所有节点都报
WAIT慢？大概率是某个从节点同步延迟严重，用ROLE和INFO replication查master_sync_in_progress和slave_repl_offset差值
最易被忽略的一点：慢日志里的 duration 是纯服务端执行耗时，不包含网络往返、pipeline 排队、客户端阻塞。如果客户端监控显示 P99 延迟突增但 SLOWLOG 没几条记录，问题大概率不在 Redis 内部，得切到客户端侧抓包或看连接池状态。
