这类慢查询命令被保存到Redis做事器的一个定长行列步队，最多保存slowlog-max-len(默认128）个慢查询命令。
当慢查询命令达到128个时，新产生的慢查询被加入前，会从行列步队中删除最旧的慢查询命令。
1.1 Redis Slowlog的配置
redis slowlog通过2个参数配置管理，默认命令耗时超过10毫秒，就会被记录到慢查询日志行列步队中；行列步队默认保存最近产生的128个慢查询命令。
slowlog-log-slower-than: 慢查询阀值,单位微秒. 默认100000(10毫秒);
生产环境设置1ms,由于Redis是single thread,如果命令都是1ms以上,则实例的吞吐量只有1000QPS.
slowlog-max-len: 慢查询存储的最大个数,默认128;
生产设置设置大于1024,由于slowlog会省略过多的参数，慢查询不会占用过多的内存；
慢查询行列步队满后,淘汰最老的慢查询实体。
1.2 Redis Slowlog读取
redis-cli客户端通过slowlog get指令获取最新10条慢查询命令。
当然各措辞的client也实现对应的接口。
示例：获取最近2个慢查询命令 127.0.0.1:6381> SLOWLOG get 21) 1) (integer) 6 2) (integer) 1458734263 3) (integer) 74372 4) 1) \"大众hgetall\"大众 2) \公众max.dsp.blacklist\"大众2) 1) (integer) 5 2) (integer) 1458734258 3) (integer) 5411075 4) 1) \公众keys\公众 2) \公众max.dsp.blacklist\"大众剖析slowlog query： 以第一个HGET命令为例剖析，每个slowlog实体共4个字段： 字段1：1个整数,表示这个slowlog涌现的序号,server启动后递增, 当前为6. 字段2：表示查询实行时的Unix韶光戳. 字段3：表示查询实行奇妙数,当前是74372奇妙,约74ms. 字段4: 表示查询的命令和参数,如果参数很多或很大,只会显示部分并给数参数个数; 当前命令是\"大众hgetall\"大众 \"大众max.dsp.blacklist\"大众
1.3 Redis Slowlog只打算命令的实行韶光
如MySQL/MongoDB等常见数据库，慢查询的query_time都会包含命令所有耗时，包含锁等待这类韶光； 而Redis的慢查询query_time只记录自己“被cpu做事的韶光”，不包含排队等待、IO等待（如AOF SYNC）这类韶光。
理解这点非常主要
参考： The Redis Slow Log is a system to log queries that exceeded a specified execution time. The execution time does not include I/O operations like talking with the client, sending the reply and so forth,but just the time needed to actually execute the command (this is the onlystage of command execution where the thread is blocked and can not serveother requests in the meantime).二、Redis Slowlog测试
设定要求的相应韶光(R),做事韶光(S), 排队延时（Q).
R = S + Q
我们回到Redis的Slowlog问题上，上节已说slowlog只打算Redis命令被做事的韶光，并不包含命令的排队延迟韶光。
2.1 现在做个测试：
1、redis实例port=6379,分别打开两个session. session-1仿照一个实行耗时6秒的大命令debug sleep 6；隔几秒后session-2实行一个大略的set a b的命令。
2、2个sessions的命令实行完成后，查看redis slowlog记录的命令耗时（slowlog-log-slower-than设置0）
session1:rendeMacBook-Pro:~ rentom$ redis-cli127.0.0.1:6379> debug sleep 6OK(6.00s)session2:127.0.0.1:6379> set name tomOK(5.14s)127.0.0.1:6379> slowlog get1) 1) (integer) 15 2) (integer) 1538980614 3) (integer) 4 4) 1) \公众set\公众 2) \"大众name\"大众 3) \"大众tom\"大众 5) \公众127.0.0.1:53738\"大众 6) \"大众\"大众2) 1) (integer) 14 2) (integer) 1538980614 3) (integer) 6001061 4) 1) \"大众debug\"大众 2) \"大众sleep\公众 3) \公众6\"大众 5) \公众127.0.0.1:53737\公众 6) \"大众\"大众
2.2 测试结论
1、从redis相应韶光监控(min列），可见set name tom命令耗时5.14s；
但从redis slowlog中查看set name tom命令耗时为4微秒，可见slowlog没有记录set命令排队延迟等待的韶光。
2、因Redis是单线程模型，debug sleep壅塞了set命令，set命令的整体相应韶光(R)是5.14S，而其做事韶光(S)为4微秒，排队延迟(Q)约为5.14秒。
三、Redis Single-threads的问题Redis Server是单线程的处理(bgsave或aof重写时会Fork子进程处理），同一韶光只能处理一个命令，并且是同步完成的。
从上节的测试中可见，set命令做事韶光只有4微秒，但被debug sleep 6命令壅塞后，相应韶光变成5.14秒。
以是RD和DBA在设计keyspace和访问模式时，应只管即便避免利用耗时较大的命令。
在空想状态下，Redis单实例能处理8~10w的QPS, 如果大量的redis命令大量耗时大于1ms, 实在QPS只能达到1000基于几百。
Redis涌现耗时大的命令，导致其他所有要求被壅塞等待，redis处理能力急剧退化，易导致全体做事链雪崩。
