Redis慢操作检测与优化技巧

Redis 通过内存中的 slowlog 环形缓冲区实时捕获执行耗时超阈值的命令（仅统计内部执行时间，不含网络与排队延迟），是其唯一原生慢操作检测机制；生产中建议将阈值调至5ms、日志长度设为1024并及时持久化配置，同时警惕 SLOWLOG GET 的局限性（如 EXEC 掩盖子命令问题、时间戳精度不足）；需摒弃 MONITOR 的长期使用，禁用 KEYS * 等高危命令，结合客户端埋点、latency 测试、内存分析及业务维度数据，才能穿透表象，精准识别偶发毛刺与系统性性能退化背后的根因。

slowlog 是唯一能实时抓到慢命令的机制

Redis 没有类似 MySQL 的慢查询日志文件，slowlog 是运行时内存中的环形缓冲区，只记录执行时间超过 slowlog-log-slower-than 阈值的命令。它不记录网络延迟、排队时间，只记命令在 Redis 内部实际执行耗时。

实操建议：

• 默认阈值是 10000 微秒（即 10ms），生产环境建议调低到 slowlog-log-slower-than 5000（5ms），避免漏掉毛刺型慢操作
• slowlog-max-len 控制最大条目数，默认 128，高并发场景建议设为 1024，否则旧记录被覆盖太快，来不及排查
• 修改后需执行 CONFIG REWRITE 持久化，否则重启丢失

用 SLOWLOG GET 查看慢命令详情

SLOWLOG GET 返回每条慢日志的 ID、时间戳、执行耗时（微秒）、命令与参数（已脱敏）。注意：参数值可能被截断，且敏感字段如密码、token 不会显示完整。

常见错误现象：

• 返回空数组 → 不代表没慢命令，可能是阈值设太高，或 slowlog-max-len 被刷满后新日志覆盖了旧的
• 看到大量 EXEC 耗时高 → 实际是整个事务里某条命令慢，slowlog 只记录 EXEC 这一动作，需结合 MONITOR 或客户端埋点定位具体子命令
• 时间戳是 Unix 秒级整数，不是毫秒，别拿它和应用层日志对不齐

示例输出中关键字段：[123, 1717024567, 18423, ["GET", "user:session:abc123"]] → ID 123，时间戳 1717024567，耗时 18423μs，执行了 GET user:session:abc123

为什么不能依赖 MONITOR 做长期慢操作追踪

MONITOR 是调试用的全量命令监听，每条命令都推送，吞吐压力极大，开启后 QPS 下降明显，部分版本甚至触发连接假死。它不区分快慢，无法过滤，也不带执行耗时字段。

使用场景仅限临时诊断，比如怀疑某类命令（如 HGETALL）批量变慢，且持续时间短于 30 秒。

实操建议：

• 绝对不要在生产环境常开 MONITOR，哪怕只开几秒也建议提前通知上下游
• 替代方案：用 redis-cli --latency 测实例响应基线，再结合 slowlog 定位突增点
• 如果必须抓全量命令+耗时，得靠客户端 SDK 自行打点（如 Go 的 redis.Hook、Java 的 LettuceCommandLatencyCollector）

KEYS * 导致的阻塞不会进 slowlog？

会进，但容易误判。因为 KEYS * 是 O(N) 全库扫描，在 key 数量大时，执行时间必然超阈值，一定会被 slowlog 记录。但问题在于：它不是“慢在某个命令逻辑”，而是“慢在设计本身”——这种命令应该被禁用，而非等它变慢才报警。

实操建议：

• 在 redis.conf 中用 rename-command KEYS "" 禁用该命令，比依赖 slowlog 更有效
• 用 SCAN 替代 KEYS，但注意 SCAN 本身不进 slowlog（单次复杂度 O(1)），不代表安全——大量 SCAN 连续调用仍可能拖垮 CPU
• Redis 7.0+ 支持 ACL LOG，可捕获被拒绝的命令（如被 rename 的 KEYS），配合 slowlog 形成双校验

慢操作追踪真正难的不是查日志，是区分“偶发毛刺”和“模式性退化”。比如某条 ZRANGE 平均 2ms，突然连续 10 次超 50ms，slowlog 只告诉你“它慢了”，但不会说“是因为这个 zset 有 2000 万成员且 score 分布极密”。这时候得结合 MEMORY USAGE、OBJECT ENCODING 和业务维度的请求参数一起看。

以上就是《Redis慢操作检测与优化技巧》的详细内容，更多关于的资料请关注golang学习网公众号！