2. 慢查询日志管理：slowlog-max-len配置、查看慢查询日志命令SLOWLOG GET、重置日志SLOWLOG RESET

慢查询日志是诊断Redis性能瓶颈的第一道防线。当某个命令的执行耗时超过预设阈值（slowlog-log-slower-than）时，Redis会将该命令的详细信息记录到一个固定长度的环形缓冲区中。本章聚焦于慢查询日志的容量控制、查询与重置操作，帮助你在消息队列场景下精准定位“拖慢”队列吞吐的元凶。

2.1 slowlog-max-len：控制日志缓冲区容量

slowlog-max-len 决定了Redis最多能保留多少条慢查询记录。默认值为128，对于高并发的消息队列生产环境，这个值往往偏小——当慢查询爆发时，早期的记录会被快速覆盖，导致排查时丢失关键线索。

运行时修改（无需重启）：

# 临时生效，重启后丢失
CONFIG SET slowlog-max-len 2048

# 持久化到 redis.conf
CONFIG REWRITE

2.2 SLOWLOG GET：查看慢查询日志

SLOWLOG GET [N] 命令用于获取最近N条慢查询记录。如果不指定N，默认返回所有记录（受 slowlog-max-len 限制）。

每条记录包含以下字段：

• ID：慢查询的唯一递增标识
• 时间戳：命令执行时的Unix时间戳（秒）
• 执行耗时：命令实际执行耗时，单位微秒
• 命令及参数：完整的命令和参数列表
• 客户端IP:端口：发起该命令的客户端地址
• 客户端名称：通过 CLIENT SETNAME 设置的名称

典型输出示例：

127.0.0.1:6379> SLOWLOG GET 2
1) 1) (integer) 15
   2) (integer) 1712345678
   3) (integer) 12005
   4) 1) "BRPOP"
      2) "queue:orders"
      3) "5"
   5) "127.0.0.1:54321"
   6) "worker-01"
2) 1) (integer) 14
   2) (integer) 1712345670
   3) (integer) 8500
   4) 1) "LRANGE"
      2) "queue:orders"
      3) "0"
      4) "100"
   5) "127.0.0.1:54322"
   6) "monitor-01"

2.3 SLOWLOG RESET：重置慢查询日志

SLOWLOG RESET 用于清空当前所有慢查询记录。该操作会重置日志ID计数器，从1开始重新编号。

适用场景：

• 性能调优前后对比：在调整 slowlog-log-slower-than 或队列配置前执行重置，确保后续记录只反映新配置下的行为。
• 问题排查阶段切换：当定位到某个慢查询并修复后，重置日志以验证修复效果。
• 监控系统周期性采集：部分监控方案会在每次拉取慢查询后执行重置，避免重复处理。

# 清空所有慢查询记录
SLOWLOG RESET

# 验证是否清空
SLOWLOG LEN
(integer) 0

2.4 慢查询日志生命周期与环形缓冲区机制

下图展示了慢查询日志从记录到被覆盖的完整生命周期，以及 slowlog-max-len 在其中的关键作用：

2.5 慢查询日志管理最佳实践

1. 设置合理的缓冲区大小：消息队列场景建议 slowlog-max-len = 2048，配合 slowlog-log-slower-than = 5000（5ms），既能捕获大部分慢查询，又不会产生过多日志。
2. 定期采集与归档：使用 SLOWLOG GET 定时（如每5分钟）拉取日志，写入外部存储（如ELK、Prometheus），避免依赖Redis内存缓冲区。
3. 区分“真慢”与“假慢”：BRPOP、BLPOP 等阻塞命令的耗时包含等待时间，不一定是真正的慢查询。可通过 SLOWLOG GET 的客户端名称字段区分消费者与监控客户端。
4. 重置后验证：在调整队列参数（如 client-output-buffer-limit）或索引结构后，执行 SLOWLOG RESET，等待5分钟后再检查新日志，确认优化效果。