slowlog 是 Redis 唯一实时捕获慢命令的机制，为内存环形缓冲区，仅记录执行耗时超阈值的命令，不包含网络延迟与排队时间；默认阈值10ms，建议调至5ms，slowlog-max-len建议设为1024，并需CONFIG REWRITE持久化。
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 和业务维度的请求参数一起看。
