Redis SLOWLOG GET 怎样读取慢命令参数

Redis 排查慢命令时，最直接的入口是 SLOWLOG GET [count]。它返回慢日志条目，默认最多取最近 10 条；每条记录的第 4 项就是命令及其参数数组，第 3 项是 Redis 实际执行命令所花的微秒数。

官方地址：https://redis.io/docs/latest/commands/slowlog-get/

SLOWLOG GET 适合回答“Redis 服务端哪些命令执行得慢、这些命令带了什么参数”。它不包含网络读写、客户端等待和发送回复的时间；如果要解释完整接口耗时，还要结合客户端链路和监控数据。

一、SLOWLOG GET 的返回结果怎样读

命令语法很简单：

# 读取默认数量的慢日志，默认最多返回最近 10 条
redis-cli SLOWLOG GET

# 只读取最近 3 条，减少本次排查的返回量
redis-cli SLOWLOG GET 3

# 读取当前慢日志中保留的全部条目
redis-cli SLOWLOG GET -1

count 是可选参数。省略它时默认返回 10 条；传入正整数时最多返回该数量；传入 -1 时返回当前慢日志保留的全部条目。命令本身按返回条目数量计费，读取的条目越多，响应和客户端解析成本越高。

二、一条慢日志的七个位置分别代表什么

Redis 官方命令文档把一条慢日志描述为一个数组。实际读取时不要只盯着命令名，而要按位置理解：

客户端名称没有设置时可能是空字符串。第 7 项是 Redis 8.10 新增的返回信息；如果服务版本较旧，不能假定每条记录都有这一项，解析器应按实际返回长度处理。

三、怎样只提取慢命令的参数数组

如果使用 redis-cli 人工排查，可以先取一条，再从第 4 项展开：

# 先清掉旧记录，避免演示数据混入当前观察窗口
redis-cli SLOWLOG RESET

# 临时把阈值设为 0，仅用于短时间观察命令参数
redis-cli CONFIG SET slowlog-log-slower-than 0

# 读取一条记录；第 4 项是命令名和参数数组
redis-cli SLOWLOG GET 1

# 观察完成后恢复一个适合业务的阈值，数值需按实际环境决定
redis-cli CONFIG SET slowlog-log-slower-than 10000

上面的阈值示例单位是微秒，只用于展示配置动作。把阈值设为 0 会让所有命令都进入慢日志，生产环境不应长时间保持这种设置。更稳妥的做法是先用 CONFIG GET slowlog-log-slower-than 记下原值，短时间采样后恢复。

程序解析时，可以把第 4 项直接当作有序数组，而不是把它拼成一条字符串再按空格拆分。这样能保留带空格的参数、二进制安全字符串和参数原始边界。

四、为什么看到的参数不完整

慢日志会受到 slowlog-max-argc 的限制。默认情况下，单条记录允许保存的参数数量有限；当命令参数超过这个上限，第 4 项的末尾会出现类似 ... (N more arguments) 的截断提示。

这时不要把截断文本当成业务参数。第 7 项记录的是命令原始参数总数，可以用它判断到底是“确实只有这么多参数”，还是“日志只保存了前面一部分”。对于 SADD、MSET 等参数数量可变的命令，这个区别尤其重要。

# 查看慢日志相关配置，先确认阈值、容量和参数保存上限
redis-cli CONFIG GET slowlog-log-slower-than slowlog-max-len slowlog-max-argc

# 只取一条记录，便于对照第 4 项和第 7 项
redis-cli SLOWLOG GET 1

如果第 4 项出现截断，而第 7 项大于已保存数组的长度，排查时应回到业务日志、调用代码或采样链路获取完整参数，不能仅凭 SLOWLOG GET 还原整条命令。

五、怎样用唯一 ID 做增量处理

如果脚本每隔一段时间读取慢日志并发送告警，可以保存上一次处理到的 ID。下一次读取后，只处理更大的 ID，避免同一条慢命令重复告警。

def new_slowlog_entries(entries, last_id):
    """只保留尚未处理的慢日志条目。"""
    fresh = []
    for entry in entries:
        # Redis 返回的第一个字段是慢日志唯一 ID，按整数比较更稳妥
        entry_id = int(entry[0])
        if entry_id > last_id:
            fresh.append(entry)
    return fresh

# 实际项目中应把新的最大 ID 持久化，而不是只放在进程内存里
last_id = 120
entries = redis_client.slowlog_get(20)
fresh_entries = new_slowlog_entries(entries, last_id)

ID 在 Redis 服务进程运行期间不会因为读取而重置，服务重启后才会重新开始。因此持久化的游标还需要记录服务实例身份；如果实例发生重启，仅比较旧实例的 ID 可能造成漏报或重复报。

六、SLOWLOG GET 的执行耗时边界

慢日志记录的是 Redis 执行命令本身的耗时，不包含与客户端通信、发送回复等 I/O 阶段。一个接口很慢，不代表它一定会在 SLOWLOG GET 中出现；反过来，命令在 Redis 内部执行较慢，也可能只是接口耗时的一部分。

因此可以按下面的顺序使用它：

1. 用 SLOWLOG GET 10 看最近是否有重复出现的慢命令。
2. 读取第 4 项，确认命令参数和 key 范围是否异常。
3. 对照第 3 项执行耗时与业务请求耗时，避免把网络等待归因给 Redis 执行。
4. 检查 slowlog-log-slower-than 和 slowlog-max-len，确认采样窗口没有过窄或过短。
5. 若参数已截断，结合第 7 项和业务日志补齐上下文。

七、常见问题

为什么 SLOWLOG GET 没有返回我刚执行的命令？

先看慢日志阈值是否高于该命令的实际执行耗时，再看记录是否被后续条目挤出保留长度。还要确认连接指向的是预期实例，而不是另一个 Redis 节点。

第 4 项参数和真实请求不一样怎么办？

优先检查是否触发了 slowlog-max-argc 截断，并用第 7 项核对原始参数总数。若服务版本没有第 7 项，只能结合应用日志或调用代码确认。

能不能用 SLOWLOG GET 直接代表接口慢？

不能。它只说明 Redis 服务端命令执行阶段超过了慢日志阈值；接口排查还应同时查看连接池、网络、客户端序列化和上游等待。

总结

SLOWLOG GET [count] 的关键不是记住一条命令，而是正确解释返回数组：第 3 项看 Redis 内部执行耗时，第 4 项读命令和参数，第 5、6 项识别客户端，第 7 项判断参数是否被截断。用 count 控制读取范围，用唯一 ID 做增量处理，再把慢日志与完整请求链路分开分析，才能得到可复现的排查结论。