Redis命令耗时怎么查，帮你快速找到性能卡点和瓶颈问题

要查找Redis命令的耗时并定位性能问题,可以从简单到复杂，采用以下几种直接有效的方法，这些方法的核心思想是观察命令执行的时间长度，找出哪些命令慢、在什么情况下慢。

使用Redis内置的慢查询日志（Slow Log）

这是最常用也是最直接的工具,Redis就像一个餐厅，慢查询日志就是记录哪些“菜”（即命令）做的时间太长了，超过了老板设定的最长时间。

• 是什么（根据Redis官方文档）： 慢查询日志是Redis一个用于记录执行时间超过指定微秒时长的命令的日志系统，它会记录命令的详细执行信息，包括执行时间、命令本身、客户端地址等。
• 怎么设置： 有两个关键配置参数，可以在redis.conf文件里修改，也可以用CONFIG SET命令直接在线调整（重启会失效，修改配置文件才能永久生效）。
  • slowlog-log-slower-than：定义“慢”的阈值，单位是微秒（1秒=1,000,000微秒），默认是10000微秒（10毫秒），如果你觉得10毫秒太宽松，可以设为5000（5毫秒）甚至1000（1毫秒），如果设为0，会记录所有命令；如果设为负数，则关闭慢查询日志。
  • slowlog-max-len：这个日志是一个先进先出的队列，这个参数指定队列的最大长度，默认是128条，当新记录进来而队列满了时，最旧的一条记录会被删除，如果系统繁忙，可以适当调大这个值，比如1024，以防漏掉重要的慢查询记录。
• 怎么看结果： 使用SLOWLOG GET [数量]命令来查看慢查询日志，不指定数量则查看全部，返回的结果会包含四个部分：
  1. 一个唯一的日志ID。
  2. 命令执行时的Unix时间戳。
  3. 命令执行的耗时,单位是微秒，这是最关键的数字。
  4. 命令本身以及其参数。 通过查看这个列表，你就能一目了然地知道是哪些命令拖慢了系统，你可能会发现一个HGETALL一个大哈希表的命令执行了200毫秒，这就是一个明显的性能卡点。

使用INFO命令查看宏观指标

慢查询日志是“抓现行犯”，而INFO命令则是看整个系统的“体检报告”，它能给你一个宏观的视角。

• 怎么看： 在Redis客户端输入INFO命令会返回海量信息，我们重点关注stats部分，可以更精确地使用INFO stats。
• 关键指标（根据Redis官方文档对INFO命令的说明）：
  • instantaneous_ops_per_sec：每秒操作数，这个值反映了Redis当前的处理能力，如果这个值相比正常时期有大幅下降，说明系统可能遇到了瓶颈。
  • total_commands_processed：自启动以来处理的总命令数，你可以隔一段时间（比如一分钟）执行一次INFO stats，然后用后一个值减去前一个值，再除以时间，也能粗略计算出每秒命令数。
  • total_net_input_bytes和total_net_output_bytes：总网络输入/输出流量，可以帮你判断是否是网络带宽成为瓶颈。

通过INFO命令，你可以先确认系统整体是否“不舒服”，然后再用慢查询日志去诊断具体的“病因”。

使用TIME命令进行简单手动计时

对于怀疑某个特定命令或一小段操作很慢的情况,可以用一个“土办法”手动计时，这就像自己用秒表掐时间。

• 怎么做： 在客户端依次执行以下命令：
  1. 执行TIME，记录下返回的当前秒数和微秒数（TIME1）。
  2. 紧接着执行你怀疑有问题的命令（比如一个复杂的LUA脚本，或者一个包含大量数据的MGET）。
  3. 再次执行TIME，记录下新的时间（TIME2）。
  4. 计算两次时间的差值：（TIME2秒 - TIME1秒） * 1000000 + （TIME2微秒 - TIME1微秒） = 总耗时（微秒）。
• 适用场景： 这种方法非常适合在测试环境或者预发布环境中，对特定的、复杂的操作进行性能验证，因为它非常精确和直接。

使用外部监控工具（例如redis-cli的--latency系列选项）

Redis自带的客户端工具redis-cli也是一个强大的延迟诊断工具。

• --latency： 运行redis-cli --latency -h，它会持续向Redis服务器发送PING命令，并统计网络往返的延迟情况，输出会显示最小、最大、平均延迟，这是检查网络层面是否稳定的好方法，如果平均延迟本身就很高（比如超过1毫秒），那命令执行慢可能不是Redis服务器的问题，而是网络问题。
• --latency-history： 和--latency类似，但它会每隔一段时间（默认15秒）输出一个采样周期的延迟统计，让你能看到延迟随时间变化的趋势。
• --intrinsic-latency： 这个命令很特别，它是在客户端本地测试机器本身的内在延迟，不连接Redis服务器，命令是redis-cli --intrinsic-latency，它测试的是你运行redis-cli的这台机器，在没有任何外部干扰的情况下，执行一个循环所能达到的最快速度，这个值可以作为一个基准，如果这个内在延迟都很高，说明可能是机器本身（比如CPU负载过高）导致了问题。

总结一下排查思路：

1. 先整体后局部： 先用INFO命令和redis-cli --latency看看系统整体健康和网络状况。
2. 抓取慢查询： 确保慢查询日志开启并设置合理的阈值，定期使用SLOWLOG GET分析，找到最耗时的命令。
3. 深入分析： 针对找到的慢命令，分析其为什么慢，常见原因有：操作了过大的Key（如一个List有几百万元素）、使用了复杂度为O(N)甚至O(N^2)的命令且N很大、Redis实例内存不足导致频繁换入换出（SWAP）等。
4. 针对性测试： 对于可疑的复杂操作，可以在测试环境用手动计时TIME的方法进行验证。

通过以上这些方法的组合使用,你就能由表及里、由宏观到微观地找到Redis的性能卡点和瓶颈所在。