Redis集群如何快速排查慢查询_使用SLOWLOG命令分析各节点的执行耗时-Redis-PHP中文网

slowlog get 是查看 redis 单节点慢查询的直接命令，返回含 id、时间戳、耗时、命令等字段的最近 n 条记录，但需手动逐节点执行、注意阈值与日志长度配置，并结合 cluster 命令定位 key 所属 slot 和节点。

redis集群如何快速排查慢查询_使用slowlog命令分析各节点的执行耗时

如何用 `SLOWLOG` 查看当前节点的慢查询记录

Redis 单节点上查慢查询最直接的方式就是 SLOWLOG GET，但它默认只返回最近 128 条（由 slowlog-max-len 控制），且不带节点标识——在集群里容易混淆是哪个分片出的问题。
执行前先确认当前连接的是目标节点（比如通过 redis-cli -h node1 -p 7001），再运行：

SLOWLOG GET 10

返回每条记录包含：唯一 ID、Unix 时间戳、执行耗时（微秒）、命令与参数（已脱敏）、客户端 IP 和端口（Redis 7.0+）。注意：slowlog-log-slower-than 默认是 10000 微秒（10ms），低于这个值不会记入日志，需按业务响应要求调整。

如果返回空，不代表没慢查询，可能是阈值设太高或日志被轮转清掉了
命令参数里的 KEYS 或 SCAN 模式匹配值会被截断，看不出具体 key，得结合 CLIENT LIST 或监控系统补全上下文
集群中每个节点都要单独连进去查，不能跨节点聚合 —— SLOWLOG 是实例级命令，不支持 CLUSTER SLOWLOG 这类语法

为什么 `SLOWLOG RESET` 在集群里要慎用

重置日志看起来是清理干扰项的好办法，但在多节点运维中容易误操作：你只连了 A 节点执行了 SLOWLOG RESET，B 节点的慢查询还在持续积累，结果排查时发现“只有 B 有慢请求”，其实只是 A 的记录被清了而已。

不要在批量巡检脚本里无条件加 SLOWLOG RESET，尤其在问题复现阶段
若真要清空，建议先 SLOWLOG GET 保存快照，再 reset；或者改用 SLOWLOG LEN 做容量判断，避免日志溢出影响性能
slowlog-max-len 设太大（如 10000）会导致内存占用上升，特别是高 QPS 集群，每个节点都存上万条记录，会挤占主内存资源

如何定位到具体是哪个 slot 或 key 导致慢查询

SLOWLOG 只给命令和耗时，不暴露 slot、key 所属节点或数据分布信息。要关联到集群拓扑，得手动做两步映射：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

从慢查询记录里提取第一个 key（如 GET user:1001 中的 user:1001），用 CLUSTER KEYSLOT user:1001 算出 slot 编号
再用 CLUSTER GETKEYSINSLOT {slot} 1 验证该 slot 是否真在这个节点上；如果不返回结果，说明 key 实际路由到了别的节点 —— 可能是客户端没启用哈希标签（{...}），或用了 MGET 跨 slot 操作触发了 ASK 重定向
特别注意 EVAL / SCRIPT LOAD 类命令：它们的慢耗时往往来自 Lua 脚本内部逻辑，SLOWLOG 只显示执行起点，得进脚本里加 redis.log() 打点

自动化采集各节点 `SLOWLOG` 的最小可行脚本

手动逐个登录太低效，可用 shell + redis-cli 快速拉取。假设集群节点列表存在 nodes.txt（每行 host:port），执行：

while read node; do
  echo "=== $node ==="
  redis-cli -h $(echo $node | cut -d: -f1) -p $(echo $node | cut -d: -f2) SLOWLOG GET 5
done 
<p>输出会混在一起，建议加时间戳和节点名前缀。更稳妥的做法是让每个节点把结果写进独立文件，再用 <code>grep -E "(100000|500000)" *.log</code> 快速筛出超 100ms 的条目。注意：如果节点启用了密码，需在 <code>redis-cli</code> 后加 <code>-a <pass></pass></code> 或用 <code>REDISCLI_AUTH</code> 环境变量，否则会卡住或报错 <code>NOAUTH Authentication required</code>。</p>
<p>真正难的不是查哪条慢，而是判断“慢是否合理”——比如 <code>GEORADIUS</code> 查 10 万点可能就是 200ms，而同样耗时的 <code>HGETALL</code> 就大概率是设计缺陷。得结合命令语义、数据规模、网络跳数一起看，别光盯着数字。</p>