直接查SLOWLOG GET是最准最快的定位方式：先CONFIG SET slowlog-log-slower-than 1000和slowlog-max-len 512动态调低阈值并扩容，再执行SLOWLOG GET 10查看最近10条含时间戳、耗时（微秒）及完整命令的记录，注意结合CLIENT LIST核对来源IP避免误判。

直接看慢查询日志，slowlog 是最准、最快定位 Redis 命令耗时问题的入口。别猜，先查。

怎么打开并读取 slowlog？

Redis 默认只记录耗时 ≥10ms 的命令，生产环境建议调低阈值。用 CONFIG SET 动态修改即可，无需重启：

• CONFIG SET slowlog-log-slower-than 1000 —— 改为记录 ≥1ms 的命令（单位是微秒）
• CONFIG SET slowlog-max-len 512 —— 扩大日志容量，避免被覆盖
• SLOWLOG GET 10 —— 查最近 10 条慢日志，每条含时间戳、耗时（微秒）、完整命令

注意：SLOWLOG RESET 可清空日志，但别在排查中误用；配置项不会持久化，需同步写入 redis.conf。

哪些命令耗时高？优先盯死这三类

不是所有慢命令都一样危险。以下三类一旦出现在 SLOWLOG 里，基本就是性能瓶颈根因：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• KEYS *：全量扫描键空间，数据量稍大就卡住整个 Redis 单线程，必须替换成 SCAN
• HGETALL、SMEMBERS、LRANGE（大范围）：返回大量数据，网络 + 序列化开销大；改用分页式命令如 HSCAN、SSCAN 或限制 LRANGE 起止索引
• 复杂 Lua 脚本：脚本内循环、嵌套遍历、未加 return 提前退出等，会阻塞主线程；用 redis-cli --eval 测试脚本本地耗时，超 1ms 就要拆或重构

耗时数字怎么看？关键不是“慢”，而是“波动”

单次 GET 耗时 5ms 不一定异常，但如果平时 0.2ms，某次突增至 8ms 且反复出现，就要怀疑背后原因：

• 是否刚触发了 RDB fork 或 AOF rewrite？查 INFO persistence 中 rdb_last_bgsave_time_sec 和 aof_last_rewrite_time_sec
• 是否有大 Key 正在被访问？用 redis-cli --bigkeys 扫描，重点关注 mem 列 >1MB 的键
• 客户端是否在循环里发单条命令？比如 for 循环调 GET 100 次 → 改用 MGET 或 Pipeline

耗时抖动比绝对值更值得警惕——它往往暴露的是系统级干扰，而非业务逻辑问题。

查到慢命令后，别急着改代码

先确认这个命令是不是真由你的服务发起的。用 CLIENT LIST 看连接来源 IP 和 addr，再结合应用日志里的 trace_id 对齐请求上下文。曾有案例：慢日志里高频出现 DEL，结果发现是另一个团队的清理脚本在定时扫库，和当前服务完全无关。

真正容易被忽略的点是：慢命令未必来自你写的业务代码，可能是 SDK 自动行为（如某些连接池健康检查用 PING）、监控探针轮询、甚至运维误操作。查 slowlog 时，务必带上 id 和 addr 一并分析。