简介

许多存储系统，例如MySQL，提供慢查询日志帮助开发和运维人员定位系统存在的慢操作。所谓慢查询日志就是系统在命令执行前后计算每条命令的执行时间，当超过预设的阈值，就将这条命令的相关信息，例如：发送时间，耗时，命令的详细信息记录下来，Redis也提供了类似的功能。

如图，Redis客户端执行一条命令分为如下四个步骤

1、 发送命令

2、命令排队

3、 命令执行

4、 返回结果

需要注意的是，慢查询只统计步骤 3 的时间，所以没有慢查询并不代表客户端没有超时问题。

Redis中获取时间阈值

那么什么样的查询是慢查询呢，大于预设阈值的查询就会被定义为慢查询，这个时间可以使用如下命令获取：config get slowlog-log-slower-than

将返回慢查询的时间阈值，单位是微妙，默认为10000微妙。

slowlog-log-slower-than=0：会记录所有的命令为慢查询。

slowlog-log-slower-than<0：对于任何命令都不会记录。

慢查询的参数配置

对于慢查询功能，需要明确两件事：

1、预设阈值怎么设置

2、慢查询记录存放在哪里？

Redis 提供了 slowlog-log-slower-than 和 slowlog-max-len 配置来解决这两个问题，从字面意思就可以看出，slowlog-log-slower-than 就是那个预设阈值，他的单位是微秒，默认值是10 000，假如执行一条很慢的命令，例如 keys * 如果他的执行时间超过了10 000 微秒，那么它将被记录在慢查询日志中。

从字面意思看，slowlog-max-len 只是说明了慢查询日志最多存储多少条，并没有说明存放在哪里？实际上 Redis 使用了一个列表来存储慢查询日志，slowlog-max-len 就是列表的最大长度，一个新的命令满足慢查询条件时被插入到这个列表中，当慢查询日志列表已处于其最大长度时，最早插入的一个命令将从列表中移除，例如slowlog-max-len 设置为5，当有第6条慢查询插入的话，那么队头的第一条数据就出列，第6条慢查询就会入列。

慢查询实际上是放到Redis的一个队列里了，但是Redis中并没有开放直接对此队列的操作。另外队列是有长度的，我们可以通过如下命令获取:config get slowlog-max-len

在Redis中有两种修改配置的方法，一种是修改配置文件，另一种是使用 config set 命令动态修改。例如下面使用 config set 命令将 slowlog-log-slower-than 设置为 20 000微秒，slowlog-max-len 设置为　1000

  config set slowlog-log-slower-than 20000
  config set slowlog-max-len 1000
  config rewrite

如果要Redis 将配置持久化到本地配置文件，需要执行 config rewrite 命令，如图：

虽然慢查询日志是存放在 Redis 内存列表中的，但是 Redis 并没有暴露这个列表的键。而是通过一组命令来实现对慢查询日志的访问和管理。下面介绍这几个命令。

获取慢查询日志

slowlog get [n]

其中的n是我们想一次获取几条的意思。如果我们不写n，就是获取所有的慢查询。下面操作返回当前 Redis 的慢查询，参数 n 可以指定条数：

127.0.0.1:6379> slowlog get
1) 1) (integer) 666
   2) (integer) 1583824076
   3) (integer) 31165
   4) 1) "zadd"
      2) "myzset"
      3) "1"
      4) "yyp"

可以看到每个慢查询日志有4个属性组成，分别是：

慢查询日志的表识ID

发生时间戳，

命令耗时

执行命令和参数

几种典型导致Redis变慢的不合理使用方式

使用keys命令进行正则匹配

Keys的正则匹配是阻塞式的、全量扫描过滤，这对于单线程服务的Redis来说是致命的，仅仅几十万个Key的匹配查询在高并发访问下就有可能将Redis打崩溃！这其实就像MySQL的无索引查询大表数据，全表扫描状态下几个并发查询就可能会将数据库堵死

大量使用了复杂度较高的命令

应用中高频使用了 O(N) 及以上复杂度的命令，例如：SUNION、SORT、ZUNIONSTORE、ZINTERSTORE 聚合类命令。SORT命令的时间复杂度：O(N+M*log(M))， N 为要排序的列表或集合内的元素数量， M 为要返回的元素数量。这种导致Redis请求变慢的原因是，Redis 在操作数据排序时，时间复杂度过高，要花费更多的 CPU计算资源

存储使用了bigkey

在分析慢日志发现很多请求并不是复杂度高的命令，都是一些del、set、hset等的低复杂度命令，那么就要评估是否写入了大key。

最佳实践

慢查询功能可以有效地帮助我们找到 Redis 可能存在的瓶颈，但在实际使用过程中要注意以下几点：

slowlog-max-len 配置建议：线上建议调大慢查询列表，记录慢查询时 Reids 会对 长命令做截断操作，并不会占用大量内存。增大慢查询列表可以减缓慢查询被剔除的可能，例如线上可设置为 1000 以上。

slowlog-log-slower-than 配置建议：默认值超过 10 毫秒判定为慢查询，需要根据 Redis 并发量调整该值。由于 Redis 采用单线程相应命令，对于高流量的场景，如果命令执行时间在 1 毫秒以上，那么 Redis 最多可支撑 OPS 不到 1000。因此对于高 OPS 场景 的 Redis 建议设置为 1毫秒。

慢查询只记录命令执行时间，并不包括命令排队和网络传输时间。因此客户端执行命令的时间会大于命令实际执行时间。因为命令执行排队机制，慢查询会导致其他命令级联阻塞，因此当客户端出现请求超时，需要检查该时间点是否有对应的慢查询，从而分析出是否为慢查询导致的命令级联阻塞。

由于慢查询日志是一个先进先出的队列，也就是说如果慢查询比较多的情况下，可能会丢失部分慢查询命令，为了防止这种情况发生，可以定期执行 slow get 命令 将慢查询日志持久化道其他存储中，例如MySQL ,然后可以制作可视化界面进行查询，好的工具可以让问题排查事半功倍。