当Redis突然变得响应缓慢，接口耗时飙升，很多问题的根源往往出在个别执行时间过长的命令上。Redis自带的SLOWLOG慢日志功能专门用来记录这些耗时命令，是性能排查中最实用的工具之一。本文将从原理、配置、命令使用和优化实践几个方面，完整讲解如何用好SLOWLOG。
一、SLOWLOG的工作原理与核心配置
SLOWLOG是Redis内置的慢查询日志系统，它会在每条命令执行前后记录时间戳并计算耗时，一旦命令执行时间超过设定阈值，就将这条命令的相关信息写入一个先进先出的内存队列中。需要注意的是，SLOWLOG记录的是命令在Redis服务端的执行时间，不包括网络传输、排队等待和序列化的时间，因此它反映的是纯粹的服务端处理开销。
理解这一点非常重要：如果客户端感知到明显的延迟，但SLOWLOG中却没有任何记录，说明瓶颈大概率出在网络、客户端或系统层面（比如fork阻塞、swap交换），而不是命令本身。这为排查方向提供了清晰的判断依据。
SLOWLOG有两个核心配置参数，可以通过配置文件或CONFIG SET命令动态修改：
# 慢查询阈值，单位微秒，默认10000（即10毫秒） # 设为0表示记录所有命令，设为负数表示关闭慢日志 CONFIG SET slowlog-log-slower-than 10000 # 慢日志队列最大长度，默认128，超出后最早的记录会被删除 CONFIG SET slowlog-max-len 1024 # 查看当前配置 CONFIG GET slowlog*
第一个参数slowlog-log-slower-than控制判定标准。线上环境通常建议设置在10000微秒左右，如果需要更精细地观察命令耗时，可以临时调低到1000甚至更低。第二个参数slowlog-max-len决定队列容量，默认的128偏小，生产环境建议调大到1000以上，避免关键慢命令记录被快速冲掉。由于慢日志存储在内存中，适当调大长度的开销非常有限。
二、SLOWLOG常用命令详解
SLOWLOG提供了三个子命令，用法都很简单，但返回结果需要正确解读。SLOWLOG GET [n]获取慢日志记录，不带参数返回全部，带数字n则只返回最近n条。每条记录包含四个部分：日志ID（单调递增）、命令发生时的Unix时间戳、命令执行耗时（微秒）以及完整的命令与参数。
# 获取最近10条慢日志 SLOWLOG GET 10 # 返回示例 # 1) 1) (integer) 14 日志ID # 2) (integer) 1712345678 发生时间戳 # 3) (integer) 25300 耗时25.3毫秒 # 4) 1) "KEYS" 命令及参数 # 2) "user:*" # 查看当前慢日志条数 SLOWLOG LEN # 清空慢日志 SLOWLOG RESET
SLOWLOG LEN返回当前队列中的记录数量，可以用来粗略判断慢命令的产生频率。如果这个数字持续快速增长，说明系统中存在稳定的慢命令来源，必须尽快定位。SLOWLOG RESET用于清空日志，通常在调整阈值后重新观察时使用，比如先把阈值调低，RESET后等一段时间再GET，就能得到更全面的耗时分布情况。
在实际运维中，建议将时间戳转换为可读时间，并结合业务流量记录交叉分析。例如某条慢命令集中在整点出现，很可能是定时任务执行了大批量操作；如果慢命令与流量高峰同步，则说明某些重命令在大数据量下性能退化明显。
三、典型慢命令场景与优化方案
分析慢日志记录时，重点关注命令类型。以下几类命令是慢日志中的常客，需要针对处理。
第一类是集合类全量操作，例如KEYS *、SMEMBERS、HGETALL、LRANGE 0 -1。这些命令的时间复杂度随数据规模线性增长，当集合元素达到几十万级别时，单次执行就可能达到数百毫秒。Redis是单线程处理命令的，一条慢命令会阻塞后续所有请求，危害极大。
优化方法是避免全量读取：遍历键改用SCAN游标分批进行，大集合读取改用SSCAN、HSCAN，并且从设计上控制单个Key的数据规模，做合理的拆分。
第二类是删除大Key。直接对包含海量元素的Key执行DEL同样会长时间阻塞主线程。Redis 4.0之后提供了UNLINK命令，它将实际的内存回收工作交给后台线程异步执行，主线程只需完成元数据摘除，几乎不产生阻塞。
# 危险：大Key直接DEL可能阻塞数百毫秒 DEL big_hash_key # 推荐：异步删除，主线程几乎无阻塞 UNLINK big_hash_key # 大集合清空也用异步方式 FLUSHALL ASYNC
第三类是复杂度较高的命令和Lua脚本。例如SORT、ZUNIONSTORE以及包含循环处理大集合的长脚本。对于这类问题，一方面要审查脚本逻辑，避免在脚本中遍历大数据；另一方面可以考虑把计算逻辑移到客户端或专门的服务中完成，让Redis专注于简单的读写职责。
最后，建议将SLOWLOG纳入常态化监控。可以通过定时任务周期性执行SLOWLOG GET并将结果上报到日志系统，同时设置慢日志条数突增的告警。配合INFO commandstats中各命令的累计耗时统计，就能构建起一套完整的Redis慢查询监控体系，在问题影响业务之前及时发现并处理。
Redis SLOWLOG慢查询Redis性能优化修改时间：2026-08-31 04:50:32