Redis集群慢查询日志不跨节点聚合，需逐个连接主节点采集；SLOWLOG RESET会丢失当前节点历史记录，建议先抽样确认再操作；timestamp为启动后毫秒数，需结合uptime_in_seconds或TIME命令换算真实时间。
Redis集群里慢查询日志默认不跨节点聚合
Redis 的 SLOWLOG 是每个实例独立维护的，集群模式下没有中心化慢查询收集机制。你连上任意一个节点执行 SLOWLOG GET，只能看到该节点的记录，其他节点的慢命令完全不可见。这意味着靠单点排查大概率漏掉真实瓶颈点。
实操建议：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 必须逐个连接所有主节点（注意：只查主节点，从节点通常不处理写/复杂读，且
SLOWLOG在从节点可能被禁用或不同步） - 用脚本批量采集，例如用
redis-cli -h {host} -p {port} SLOWLOG GET 10遍历所有主节点 IP:端口 - 别依赖
slowlog-log-slower-than的全局配置——它在每个节点单独生效，需确认所有主节点配置一致，否则有的节点记、有的不记
如何安全地清空慢查询日志而不影响线上？
SLOWLOG RESET 是原子操作，但会清掉当前节点全部历史记录。问题在于：如果你正在排查问题，又误在某个节点执行了 reset，就丢失了关键线索；更麻烦的是，集群中多个节点日志时间线不一致，reset 后无法对齐分析。
实操建议：
- 执行前先用
SLOWLOG LEN看当前条数，再用SLOWLOG GET 5抽样确认内容是否关键 - 避免在业务高峰期间执行
SLOWLOG RESET，尤其不要在未确认节点角色（主/从）时直接跑脚本批量重置 - 如果只是想控制日志体积，优先调大
slowlog-max-len（比如设为 1000），而不是频繁清空——日志本身内存开销极小，真正耗资源的是解析和传输过程
为什么 redis-cli --cluster call 不能直接拿到所有节点慢日志？
redis-cli --cluster call 确实能向所有节点发命令，但 SLOWLOG GET 返回的是数组结构，而 --cluster call 默认把各节点响应拼成一个扁平字符串，导致 JSON 解析失败或字段错位。你看到的输出往往是乱序、截断甚至报错的。
实操建议：
- 放弃
--cluster call直接获取慢日志，改用循环调用redis-cli -c（注意加-c避免 MOVED 重定向干扰） - 用 Python 或 Bash 脚本封装，对每个节点输出加上 host:port 前缀，例如：
echo "[$host:$port]"; redis-cli -h $host -p $port SLOWLOG GET 10 - 如果要用 Go/Python 客户端，注意部分库（如 redis-py）对
SLOWLOG GET返回的嵌套数组解析不稳定，建议手动 decode 响应原生数组
慢查询里 timestamp 字段不是 Unix 时间戳，而是相对启动时间的毫秒数
这个细节坑过很多人：SLOWLOG GET 返回每条记录里的 timestamp 是 Redis 实例启动后经过的毫秒数，不是标准时间。直接拿它去比对其他系统日志（比如应用层打点或监控系统时间）会完全对不上。
实操建议：
- 用
INFO server中的uptime_in_seconds换算：实际时间 = 实例启动时间 +timestamp/ 1000 - 更稳妥的做法是，在采集慢日志的同时，用
TIME命令获取节点当前时间，再结合timestamp反推命令执行时刻 - 如果节点发生过重启，
timestamp会归零，此时仅靠它无法跨重启追溯——必须依赖外部时间戳打点或日志关联
execution_time，先校准时间再分析。 
