redis慢日志不直接记录内存淘汰耗时，但当slowlog-log-slower-than设过低（如1000微秒）时，会将因淘汰操作拖累而变慢的正常命令（如get、hget）误判为慢查询，因其执行时间被前置淘汰占用导致“被波及”，从而产生噪声；设过高则可能漏掉真实淘汰引发的10–20ms延迟毛刺。
Redis慢日志本身不直接记录内存淘汰耗时，但能间接暴露淘汰引发的延迟——关键看命令执行时间是否异常拉长，且日志中出现大量 GET、HGET、LPOP 等简单命令却耗时数毫秒甚至几十毫秒。
为什么 slowlog-log-slower-than 设得太低会“误报”淘汰延迟
内存淘汰（eviction）发生在主线程处理命令前或后，它不产生独立日志条目，但会显著拖慢后续命令的实际执行时间。如果 slowlog-log-slower-than 设为 1000（1ms），而一次淘汰操作占用了 2ms CPU 时间，那么紧随其后的那条 GET 命令就可能被记为慢日志——不是它自己慢，是它“撞上了淘汰”。
-
slowlog-log-slower-than设得越小，越容易捕获到这种“被波及”的命令，但也带来更多噪声；设得太大（如 50000），可能漏掉真实由淘汰引发的 10–20ms 毛刺 - 线上建议先设为
5000（5ms），再结合INFO memory中的evicted_keys增速判断：若每秒evicted_keys增加 >500，同时慢日志里GET/HGET频繁出现 6–15ms 耗时，基本可锁定淘汰干扰 - 注意：
slowlog-log-slower-than 0会记录所有命令，看似全面，实则淹没关键信号——你无法从上万条日志里快速识别出哪几条是“被拖慢”的
slowlog get 输出里哪些特征指向淘汰压力
查 SLOWLOG get 10 时，别只盯命令名，重点看耗时分布和参数模式：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 同一类简单命令（如
GET、HGET、EXISTS）集中出现在慢日志里，且耗时集中在 4–20ms 区间，而非偶发单条 50ms+，这是淘汰高频触发的典型痕迹 - 命令参数明显是热 key（如
"user:1001"、"session:abc"），但执行时间远超平时（平时应 - 时间戳列（第二项）显示多条日志集中在同一秒内爆发，比如 5 条日志的时间戳都是
1748485920（相差 INFO memory 里该秒evicted_keys突增 300+ - 避免误判：如果慢日志里大量出现
KEYS、LRANGE user_list_2000 0 -1这类 O(N) 命令，优先排查业务逻辑，而非淘汰
CONFIG SET slowlog-log-slower-than 的生效与陷阱
这个配置能热更新，但有隐含行为必须清楚：
- 修改后立即生效，但**不会重放历史命令**——已执行完的命令不会因阈值调低而补录
- 用
CONFIG REWRITE才会写入redis.conf；否则实例重启后恢复默认10000 - 如果 Redis 正在高负载，频繁
CONFIG SET可能短暂加剧延迟（虽小，但敏感场景需避开高峰） - 某些云厂商托管 Redis（如阿里云 Tair、腾讯云 CRS）限制
CONFIG SET权限，此时只能改配置文件并重启——重启本身会清空 slowlog，丢失现场线索
真正要盯的不是 slowlog-log-slower-than，而是 evicted_keys + latency
靠慢日志定位淘汰延迟，本质是“借壳探测”。更直接的方式是组合监控：
- 用
redis-cli --latency-history -i 1持续采样，观察输出中是否周期性出现eviction类型的尖峰（如max: 28.4 ms (eviction)） - 写个脚本每 2 秒跑一次
INFO memory | grep -E "used_memory_human|evicted_keys|maxmemory"，计算evicted_keys差值 —— 持续 >300/sec 就说明淘汰已成常态 -
slowlog-log-slower-than只是放大镜，不是诊断仪；它调得再细，也看不到淘汰本身花了多少微秒，只能告诉你“此刻系统很忙”
