Redis 出现响应变慢时，常见的第一反应是检查网络抖动、客户端连接池或者服务器基础负载，却容易忽略服务端命令本身的执行耗时。Redis 提供了一套轻量级的慢查询日志系统，能够记录执行时间超过指定阈值的命令，帮助开发者从命令粒度定位性能瓶颈。只要配置得当，慢查询日志可以成为排查偶发卡顿、接口超时和 CPU 飙高等问题的重要线索。

慢查询日志并不记录网络传输时间或客户端等待时间，它只统计命令在 Redis 服务端实际执行所消耗的时间。这一特性让它可以更直接地反映命令复杂度、数据结构大小和阻塞操作带来的影响。接下来会从参数机制、日志解读、典型优化场景和长期监控四个角度展开。

一、慢查询日志的工作机制与参数配置

Redis 慢查询日志由两个核心参数控制。slowlog-log-slower-than 表示执行时间阈值，单位是微秒，默认值为 10000，也就是 10 毫秒。只有执行时间超过该阈值的命令才会被记录。另一个参数 slowlog-max-len 表示日志队列的最大长度，默认是 128 条。慢查询日志保存在 Redis 服务端的一块内存区域中，采用先进先出策略，当记录数量超过上限时，最旧的记录会被删除。

如果希望捕捉更多慢命令，可以把阈值调低，例如设置为 5000 微秒；如果只想关注严重阻塞，可以设置为 20000 微秒。将 slowlog-log-slower-than 设置为 0 会记录全部命令，设置为负数则关闭慢查询日志。由于日志只保存在内存中，不会写入磁盘，因此记录本身对 Redis 的性能影响很小，但过低的阈值可能产生大量日志，占用额外内存，需要根据实际场景权衡。

# redis.conf 配置示例
slowlog-log-slower-than 10000
slowlog-max-len 128
# 运行时动态调整
CONFIG SET slowlog-log-slower-than 5000
CONFIG SET slowlog-max-len 256
CONFIG REWRITE

需要特别注意的是，慢查询日志会记录命令的完整参数，包括 key 名称和传入的值。如果业务中曾经有敏感信息作为命令参数传入，日志中也会原样保留。因此，慢查询日志的读取权限需要加以控制，并避免在不安全的环境中随意导出。

二、如何获取并解读慢查询日志

读取慢查询日志最直接的方式是使用 SLOWLOG GET 命令。该命令可以指定返回条数，例如 SLOWLOG GET 10 会返回最近 10 条慢查询记录。每条记录包含唯一编号、时间戳、执行耗时、命令参数数组、客户端地址与名称。其中执行耗时同样以微秒为单位，便于与阈值进行对比。

SLOWLOG GET 5
# 示例输出
1) 1) (integer) 17
   2) (integer) 1700000000
   3) (integer) 15012
   4) 1) "KEYS"
      2) "user:*"
   5) "192.168.1.20:55012"
   6) ""

上面这条日志表示命令 KEYS user:* 在服务端执行了 15012 微秒，约 15 毫秒，来源客户端地址为 192.168.1.20。配合业务请求时间点和 key 命名规则，可以快速判断是哪一类业务操作触发了慢查询。使用 SLOWLOG LEN 可以查看当前日志条数，使用 SLOWLOG RESET 可以清空日志，便于重新采样。

解读日志时不能只看单条记录，需要结合时间分布判断问题是否具有持续性。如果某个命令偶尔出现一次高耗时，可能与当时的数据量瞬间增大、内存碎片或操作系统调度有关；如果同一类命令频繁出现在慢查询日志中，则说明数据规模或命令用法已经不适合当前 Redis 实例。重点关注的通常不是命令名称本身，而是命令背后的数据量级和时间复杂度。例如 KEYS、SMEMBERS、HGETALL、LRANGE 0 -1 都属于 O(N) 命令，当集合元素数量增长后，执行时间会线性上升。

三、典型慢查询场景与优化方法

3.1 大Key与O(N)命令

大 key 是慢查询最常见的诱因之一。一个包含几十万个元素的列表、哈希或集合，即使执行一次 HGETALL 或 SMEMBERS 也可能消耗几十毫秒甚至更长时间。KEYS 命令更是需要遍历整个键空间，在生产环境中几乎必然造成阻塞。定位大 key 可以使用 redis-cli --bigkeys 工具，它会扫描所有 key 并统计各类型中最大的若干 key。针对单个 key 的内存占用，可以使用 MEMORY USAGE 命令。

redis-cli --bigkeys
# 查看某个 key 的内存占用
MEMORY USAGE user:session:1001

优化大 key 带来的慢查询，核心思路是避免一次性处理全部数据。对于需要遍历键空间的场景，应该使用 SCAN 替代 KEYS。虽然 SCAN 无法保证精准计数，但它通过游标分批返回结果，不会长时间阻塞 Redis 主线程。对于哈希结构，尽量使用 HMGET 获取指定字段，而不是整表拉取。对于列表，严格控制范围，例如 LRANGE list 0 99，避免使用 LRANGE list 0 -1 全量读取。更彻底的方案是进行数据拆分，将大 key 拆成多个小 key，或者采用哈希分桶降低单个 key 的规模。

# 不推荐：全量获取哈希所有字段
HGETALL order:20240101:detail
# 推荐：按具体字段获取
HMGET order:20240101:detail amount status buyer_id
# 不推荐：全表扫描匹配键
KEYS session:*
# 推荐：游标迭代
SCAN 0 MATCH session:* COUNT 1000

3.2 过期键集中失效与删除阻塞

Redis 清理过期键采用惰性删除和定期删除相结合的策略。如果大量 key 在同一时间点过期，定期删除任务就会在很短的时间内集中处理大量键，导致主线程被阻塞。这种阻塞不一定会直接体现在某一条命令的慢查询中，但会拉高整体延迟，并可能让其他本来很快的命令也被记录为慢查询。典型表现是每隔一段时间出现一批慢日志，且时间点与业务缓存写入高峰重合。

解决过期键集中失效的方法是让过期时间分散化。业务在设置缓存 TTL 时，可以在基础过期时间上增加一个随机偏移量，例如 600 秒到 720 秒之间，避免所有缓存同时过期。对于删除大 key 或需要清理大量数据的情况，优先使用 UNLINK 替代 DEL。UNLINK 会将 key 的删除操作转入后台异步处理，减少主线程阻塞时间。

# 应用层生成带随机偏移的过期秒数，例如 600 到 720 之间
SET cache:goods:1001 goods_data EX 637
# 删除大 key 时使用异步命令
UNLINK big:list:queue

3.3 Lua脚本与复杂计算

Redis 支持通过 Lua 脚本执行多个命令，并能保证原子性。但如果 Lua 脚本内部包含复杂的循环、大量数据的排序或聚合操作，脚本执行期间 Redis 主线程会被完全占用，其他客户端请求只能等待。慢查询日志中会显示 EVAL 或 EVALSHA 命令，以及脚本涉及的 key 和参数。

优化 Lua 脚本的关键是缩短单次脚本的执行时间，而不是把所有逻辑都塞进 Redis。对于排行榜这类需要排序的场景，可以限制返回的 top N 数量，避免对超大有序集合进行全量排序。对于复杂统计，可以将计算过程迁移到离线任务或应用层，Redis 只负责存储和基础读写。使用 ZREVRANGE 直接获取前 100 名，通常比在 Lua 中循环处理更直观，也更容易控制耗时。

# 慢日志中可能看到 EVAL 执行耗时
EVAL "return redis.call('ZREVRANGE', KEYS[1], 0, 99)" 1 leaderboard:global
# 优化：用 ZREVRANGE 直接获取，并限制分页大小
ZREVRANGE leaderboard:global 0 99 WITHSCORES

四、慢查询监控与长期优化建议

慢查询日志本身不会主动告警，需要结合外部监控来持续跟踪。可以编写脚本定期执行 SLOWLOG GET，解析命令、耗时和发生时间，将结果推送到监控系统或时序数据库。拉取频率一般控制在 10 秒到 60 秒之间，既能及时发现慢查询，又不会给 Redis 增加明显负担。当单位时间内的慢查询数量超过阈值，或者最大执行耗时超过预警值时，触发告警通知开发人员。

# 查看服务端内部延迟
redis-cli --intrinsic-latency 5
# 查看客户端到服务端的延迟历史
redis-cli --latency-history -i 1

除了直接使用慢查询日志，还可以借助 redis-cli --intrinsic-latency 检查 Redis 服务端自身的调度延迟，用 redis-cli --latency-history 观察客户端到服务端的网络延迟变化。这些工具能帮助判断问题究竟出在命令执行、网络链路还是系统环境。慢查询日志适合定位命令级耗时，但网络抖动、持久化 fork、内存碎片等问题还需要配合其他指标一起分析。

长期优化需要从键设计和容量规划入手。定期执行 redis-cli --bigkeys 发现大 key，及时拆分或清理；对高基数集合优先选择 HyperLogLog、Bitmap 等更节省空间的结构；热路径命令尽量保持 O(1) 复杂度；对于读多写少的热点 key，可以增加客户端本地缓存或使用多级缓存架构。慢查询日志不是全部，但它是定位 Redis 性能问题最直接、最易落地的入口。只要形成定期查看和自动告警的习惯，大部分命令级性能瓶颈都能在影响扩大前被发现并解决。