Redis基础

上一篇我们借助Redis INFO命令实现了基础性能监控，能快速查看内存、连接、命中率等核心指标，判断Redis是否处于健康状态。但在实际线上场景中，经常遇到Redis莫名卡顿、响应延迟飙升，仅凭INFO指标很难定位根源——这时候就需要慢查询日志出马，精准锁定那些执行耗时过长的“问题命令”。

Redis慢查询日志是内置的轻量级监控工具，专门记录超过指定阈值的命令，无需额外采集、不占用过多资源，是排查Redis性能瓶颈的核心利器。本篇从零入门Redis慢查询，从配置开启、日志查看、问题定位到优化方案，带你彻底搞定Redis命令耗时问题。

核心定位：Redis慢查询日志用于记录执行时间超过预设阈值的命令，帮助开发者快速定位低效命令、大Key操作、不合理查询，是Redis性能调优的必备工具。

一、先搞懂：Redis慢查询的核心原理

很多新手会误解慢查询的统计范围，先厘清关键细节，避免排查踩坑：

  • 慢查询统计的是什么时间？ 只统计命令实际执行耗时，不包含网络传输、客户端排队等待时间，也就是说：慢查询=命令执行超时，而非整个请求链路超时。
  • 慢查询日志存在哪里？ 默认存储在Redis内存中，不是磁盘文件，重启后日志会清空；可配置持久化落地（可选）。
  • 哪些命令会被记录？ 所有执行耗时超过阈值的命令都会被记录，比如KEYS、HGETALL、LRANGE、SORT等全量遍历命令，操作大Key的命令。

重要提醒：慢查询只关注命令执行阶段，若Redis响应慢但无慢查询，大概率是网络拥堵、连接数爆满、CPU抢占导致的，需结合INFO命令排查。

二、两步开启：慢查询日志配置

Redis慢查询默认未开启（或阈值过高），需通过配置文件或动态命令设置，推荐动态配置+永久配置结合，既生效快又能持久化。

1. 核心配置参数

配置项作用默认值推荐配置
slowlog-log-slower-than慢查询阈值，单位：微秒（1秒=1000毫秒=1000000微秒）10000（10毫秒）5000（5毫秒），业务敏感场景设1000（1毫秒）
slowlog-max-len慢查询日志最大保留条数（内存队列长度）1281000（避免频繁覆盖日志）

💡 阈值说明：阈值设为0表示记录所有命令；设为负数表示关闭慢查询。

2. 动态开启（立即生效，无需重启）

连接Redis客户端，执行以下命令，线上优先用这种方式，不影响业务：

# 1. 设置阈值：超过5毫秒的命令记为慢查询
127.0.0.1:6379> CONFIG SET slowlog-log-slower-than 5000
OK

# 2. 设置最大日志条数：保留1000条记录
127.0.0.1:6379> CONFIG SET slowlog-max-len 1000
OK

# 3. 查看当前慢查询配置
127.0.0.1:6379> CONFIG GET slowlog*
1) "slowlog-log-slower-than"
2) "5000"
3) "slowlog-max-len"
4) "1000"

3. 永久配置（重启生效）

修改redis.conf配置文件，添加/修改以下参数，防止重启后配置失效：

# 慢查询阈值：5毫秒
slowlog-log-slower-than 5000
# 最大日志条数
slowlog-max-len 1000

三、核心操作：慢查询日志查看与管理

Redis提供SLOWLOG命令，专门用于查看、清空慢查询日志，语法简洁易懂。

1. 查看慢查询日志

# 查看所有慢查询日志
127.0.0.1:6379> SLOWLOG GET

# 查看最近N条慢查询（推荐，避免输出过多）
127.0.0.1:6379> SLOWLOG GET 10

# 查看慢查询日志总条数
127.0.0.1:6379> SLOWLOG LEN

2. 慢查询日志字段解读

每条慢查询日志包含4个核心字段，按顺序展示：

  1. 日志ID：唯一标识，自增不重复
  2. 执行时间戳：命令执行的时间点
  3. 执行耗时：单位微秒，超过阈值才会记录
  4. 命令详情：完整命令+参数，定位具体操作
# 慢查询日志示例
1) 1) (integer) 5           # 日志ID
   2) (integer) 1742530000  # 执行时间戳
   3) (integer) 8500        # 耗时：8500微秒=8.5毫秒
   4) 1) "KEYS"             # 命令详情
      2) "*"

3. 清空慢查询日志

日志积累过多时，可手动清空内存中的慢查询记录：

# 清空所有慢查询日志
127.0.0.1:6379> SLOWLOG RESET
OK

四、高频慢查询命令与典型场景

线上90%的慢查询都出自以下几类命令，优先排查这些操作：

  • KEYS pattern：全量遍历Key，禁止线上使用，数据量大时直接卡死Redis
  • HGETALL、SMEMBERS、LRANGE 0 -1：全量获取哈希、集合、列表数据，操作大Key必慢
  • SORT、SUNION、SINTER：集合排序、交集并集计算，复杂度高
  • 大量DEL大Key：删除超大哈希/列表，阻塞主线程
  • 循环执行小命令：批量循环GET/SET，频繁IO导致耗时累加

典型慢查询案例

  1. 用KEYS *查询所有Key，数据量100万+，耗时几十毫秒
  2. HGETALL一个包含10万字段的大哈希，执行超时
  3. LRANGE获取一个超长列表的全部元素，耗时飙升

五、慢查询优化：从根源解决耗时问题

找到慢查询后，针对性优化，彻底解决Redis卡顿：

1. 禁用高危命令

  • 禁用KEYS，改用SCAN命令渐进式遍历
  • 禁用全量获取命令，改用HSCAN、SSCAN分页查询
  • redis.conf中用rename-command重命名高危命令，防止误执行

2. 拆分大Key

大Key是慢查询元凶，将超大哈希、列表、集合拆分为多个小Key，分散压力；用Redis CLI自带的redis-cli –bigkeys命令快速扫描大Key。

3. 优化命令使用

  • 批量操作改用管道（Pipeline），减少网络IO次数
  • 避免在高并发场景执行复杂命令
  • 删除大Key改用UNLINK（异步删除），替代阻塞式DEL

4. 合理设置阈值

根据业务容忍度调整阈值，核心接口建议设为1毫秒，及时发现微小耗时问题。

六、慢查询最佳实践与避坑

  • 定期查看：每天巡检慢查询，提前发现隐患，避免故障爆发
  • 不要依赖默认配置：默认10毫秒阈值太宽松，建议调低至5毫秒内
  • 日志持久化：重要环境将慢查询日志落地到文件，防止重启丢失
  • 结合监控：慢查询+INFO命令+内存监控，全方位定位性能瓶颈
  • 勿过度依赖：慢查询不记录网络耗时，排查全链路延迟需结合链路追踪

慢查询速记：阈值设好抓超时，SLOWLOG GET查详情；高危命令要禁用，大Key拆分是关键；定期巡检不偷懒，Redis卡顿全跑光。 核心命令：SLOWLOG GET、CONFIG SET slowlog-log-slower-than

结语与下篇预告

本篇我们掌握了Redis慢查询日志的配置、查看、定位与优化，彻底解决命令执行耗时过长的问题，让Redis运行更流畅。

发表回复