持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第10天，点击查看活动详情

所谓慢查询日志就是计算每条命令执行的时间，当超过我们设定的阈值的时候就把这条命令相关的信息记录下来。

在redis中，一条命令执行需要经历以下四个阶段

1. 发送命令
2. 排队
3. 执行命令
4. 返回结果

对于redis来说，慢查询日志只针对于执行命令这个操作，也就是只监控命令执行的时间长短，而记录日志。

慢查询的两个配置参数

对于我们需要分析的开发人员来说，想要去分析这个慢查询，无非注意两件事情，如可开启这个慢查询日志和在哪去查看这个慢查询日志。

对于redis来说，有两个配置来帮助我们解决两个问题

• slowlog-log-slower-than，从字面意思就可以看出，这个是慢查询日志的阈值，单位是微秒，默认是10000，也就是10毫秒。也就是说当命令执行的时长超过10毫秒的时候将被记录在慢查询日志中。
• slowlog-max-len 表示慢查询最大的保存条数，redis使用了一个列表来保存慢查询日志，slowlog-max-len就是这个列表的最大长度，当慢查询列表已经到达最大长度还需要新增的时候，最早插入的一条记录会被删除掉。

slowlog-log-slower-than设置为0的时候，所有命令将被记录，设置为负数则不记录任何命令

比如我们为了测试，把测试环境的配置改为记录所有，并且慢查询列表长度为500，想要将命令修改的配置持久化到配置文件，需要执行config rewrite命令

127.0.0.1:6379> config set slowlog-log-slower-than 0
OK
127.0.0.1:6379> config set slowlog-max-len 500
OK
127.0.0.1:6379> config rewrite

这时候我们可以使用命令slowlog get [n]查看慢查询。

127.0.0.1:6379> slowlog get
1) 1) (integer) 42
   2) (integer) 1665233495
   3) (integer) 3
   4) 1) "set"
      2) "name"
      3) "luke"
2) 1) (integer) 41
   2) (integer) 1665233490
   3) (integer) 23
   4) 1) "slowlog"
      2) "reset"

从返回结果可以看出，慢查询日志由四个部分组成：

1. id
2. 时间戳
3. 耗费时间
4. 执行的命令

同时我们也可以查询慢查询列表的长度

127.0.0.1:6379> slowlog len
(integer) 3

重置慢查询列表

127.0.0.1:6379> slowlog reset
OK

最佳实践

慢查询日志可以帮我们在开发中和生产分析中快速找到瓶颈，但当我们使用的时候还应注意以下几点

slowlog-log-slower-than配置建议

这个值可以适当的设置大一点，因为redis记录慢查询日志的时候会对长命令做截断操作，所以并不会占用很大的内存，这个阈值设置的大一点，可以防止丢失部分慢查询日志。

slowlog-max-le配置建议

slowlog-max-len默认是10毫秒。但是redis是单线程模型，所以若是每条命令执行时间为1毫秒，则一秒钟才能执行1000条，QPS才为1000。因此对于高并发的场景建议设置为1毫秒。

分析建议

慢查询会阻塞redis，所以有客户端超时发生时，可以查看下是不是在那个时间点发生了慢查询。

持久化

因为慢查询队列是有大小的，遵循先进先出，所以我们可以定期将慢查询日志持久化到数据库，然后制作可视化界面进行分析。之后我们会聊到Redis的私有云CatchCloud就提供了这样的功能。