当 Redis 实例的响应时间突然升高，第一步往往是确认到底哪些命令执行得慢。此时如果直接在 redis-cli 里输入 SHOWLOG，大概率会收到 ERR unknown command，因为 Redis 并没有 SHOWLOG 这个命令，真正用于记录慢命令的机制叫 SLOWLOG。这个命名差异已经让不少从关系型数据库转过来的开发者踩坑。SLOWLOG 记录的是执行耗时超过指定阈值的命令，它以内存队列的形式存在，不依赖外部日志文件，查看成本非常低。
慢查询日志并不是 Redis 独有的概念，MySQL、MongoDB 等数据库也有类似机制，但 Redis 的实现更轻量。它不会把内容写入磁盘，而是维护一个固定长度的内存列表，一旦写满就淘汰最旧的记录。因此即使日志丢失，也不会影响 Redis 的数据持久化。理解这一点，对后续参数调优和容量规划非常重要。
一、SLOWLOG 的命令结构与参数机制
在 redis-cli 中执行 SLOWLOG HELP 可以看到它支持的子命令，核心只有三个：SLOWLOG GET [count]、SLOWLOG LEN 和 SLOWLOG RESET。GET 用于返回最近若干条慢查询记录，LEN 返回当前积压的慢查询数量，RESET 清空整个慢查询日志。日常排查一般按照先看数量、再取详情、分析完按需清空的顺序操作。
控制慢日志行为的两个参数位于 redis.conf 或运行时配置中：slowlog-log-slower-than 表示耗时阈值，单位是微秒，默认 10000，也就是 10 毫秒；slowlog-max-len 表示最多保存多少条记录，默认 128。二者可以动态调整，无需重启 Redis：
CONFIG SET slowlog-log-slower-than 10000 CONFIG SET slowlog-max-len 128 CONFIG GET slowlog-*
这里有一个需要特别注意的地方：阈值单位是微秒而不是毫秒。想记录超过 5 毫秒的命令，应写成 5000，而不是 5。如果设为 0，Redis 会记录所有命令，常用于短期调试；如果设为负数，则关闭慢查询记录。因为记录本身也会消耗少量 CPU 和内存，生产环境不建议长期设为 0。
每条慢查询记录的字段顺序通常为：唯一 ID、Unix 时间戳、执行耗时（微秒）、命令参数数组、客户端地址、客户端名称。命令参数数组会完整记录真实命令及参数，例如 KEYS pattern 或 GET key，这给问题复现和参数分析提供了直接依据。
二、一次完整的慢查询排查演示
假设一个订单缓存服务在晚间突然出现批量超时，可以先通过 SLOWLOG LEN 确认实例上是否积压了慢查询：
127.0.0.1:6379> SLOWLOG LEN (integer) 17
返回 17 说明目前有 17 条慢命令未被淘汰。接着拉取最近 5 条，使用 SLOWLOG GET 5。输出会按发生时间倒序排列，最新一条在最前面，里面最关键的是第 3 个字段耗时和第 4 个字段命令数组。例如看到 KEYS order:* 耗时 85213 微秒，说明这条命令扫描了大量键。
127.0.0.1:6379> SLOWLOG GET 2
1) 1) (integer) 104
2) (integer) 1719238400
3) (integer) 85213
4) 1) "KEYS"
2) "order:*"
5) "127.0.0.1:49872"
6) ""
2) 1) (integer) 103
2) (integer) 1719238388
3) (integer) 62110
4) 1) "HGETALL"
2) "cart:user:10021"
5) "127.0.0.1:49891"
6) ""
第一条 KEYS order:* 的耗时异常明显，通常是因为线上误用 KEYS 命令遍历所有键。结合业务场景可以改为 SCAN 游标分批遍历，或者在写入时维护一个订单索引集合。第二条 HGETALL cart:user:10021 说明某个购物车哈希字段过多，单次全量拉取导致阻塞，可考虑拆字段或只取需要的 field。
排查结束后，如果确认这些记录已经处理完毕，可以执行 SLOWLOG RESET 清空历史，让下一次排查不受旧数据干扰。但要注意，清空操作不可恢复，如果有审计或后续分析需求，应先通过客户端工具导出再重置。
三、高频误区：这些理解偏差会让排查方向跑偏
第一个误区是把命令名写成 SHOWLOG。在 MySQL 中 SHOW LOGS、SHOW VARIABLES 等语句让很多人形成了 SHOW 开头的习惯，但 Redis 使用的是 SLOWLOG，两者虽然只差一个字母，含义完全不同。SHOWLOG 会直接返回未知命令错误，而不是查看慢查询。
第二个常见误区是以为慢查询日志会写入磁盘文件，并尝试去日志目录找类似 slow.log 的文件。实际上 Redis 慢查询日志只保存在内存里，达到 slowlog-max-len 后会淘汰最旧记录，进程重启即清空。需要持久化分析时，应该把 SLOWLOG GET 的结果导出到外部系统，或者使用 Redis 客户端库定期采集。
第三个误区是认为阈值设得越低越好，或记录条数越多越好。阈值设成 0 会让所有命令写慢日志，不仅增加 CPU 与内存开销，还可能引入大量噪声，反而掩盖真正的慢命令。记录条数过大同样会占用额外内存，如果单条命令参数非常长，几百条记录也可能明显增加内存占用。一般建议阈值从 5 到 10 毫秒起调，最大条数保持在 128 到 512 之间。
第四个误区是只关注单条命令耗时，不分析命令复杂度和数据结构规模。比如一条 GET 命令耗时很高，不一定是命令本身慢，而可能是对应 value 体积过大、网络延迟或实例 CPU 被其他命令占满。慢日志提供的是入口信息，还需要结合命令复杂度、键大小和业务调用链一起判断。
四、生产环境实用建议
在正式接入 SLOWLOG 之前，可以先根据业务延迟预算设定合理阈值。普通缓存读通常要求在 1 毫秒以内，那么阈值可以设为 2000 微秒；后台批量任务或允许稍高延迟的服务可以放宽到 10000 微秒。切忌所有环境都套用同一个默认值，因为慢查询的“慢”是相对业务目标而言的。
参数调整建议通过 CONFIG SET 生效后，再同步修改 redis.conf，避免重启后配置回退。内存方面可以简单估算：每条慢日志包含命令、参数、客户端信息，通常占用几十到几百字节。