不能。Latency Monitor需手动启用eviction事件并设合理阈值（如10ms）才能捕获淘汰耗时；若LATENCY HISTORY eviction为空，通常因未触发淘汰（如maxmemory-policy为noeviction、内存未超限或阈值过高），而非监控失效。
Latency Monitor能直接测出淘汰耗时吗
不能。redis-cli --latency 和 redis-cli --latency-history 测的是客户端到服务端的往返延迟，不包含淘汰逻辑执行时间；redis-cli --intrinsic-latency 测的是 Redis 内部事件循环空转延迟，也**不触发淘汰路径**。真正能捕获淘汰动作耗时的，是 Redis 自带的延迟监控框架（latency monitor），但它需要显式启用且只记录超过阈值的“慢操作”事件，其中就包括 eviction 类型。
怎么开启并验证eviction延迟监控
必须先设置阈值，否则 eviction 事件永远不会被记录：
-
CONFIG SET latency-monitor-threshold 10—— 单位毫秒，建议设为 5–20ms（太低会刷屏，太高漏信号） - 执行几轮写压测（如
redis-benchmark -n 10000 -t set），确保触发内存淘汰（used_memory_human≥ 95%maxmemory） - 运行
LATENCY LATEST查看最新事件：若看到eviction类型且min/max值明显高于其他类型（如 >5ms），说明淘汰已构成延迟瓶颈 - 用
LATENCY HISTORY eviction查历史尖峰，配合时间戳比对业务日志中的超时请求
eviction延迟高时，业务最常出现什么现象
因为淘汰是同步阻塞主线程的，一旦单次淘汰耗时超标，所有后续命令都会排队等待。典型表现有：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
instantaneous_ops_per_sec突然下跌 30% 以上，而total_commands_processed增速变缓 -
keyspace_misses暴涨（缓存穿透加剧），但evicted_keys同步跳升 —— 说明刚淘汰完，新请求又打进来，反复淘汰 - 客户端报
READ timeout或Connection reset，但redis-cli --latency显示网络延迟正常 - 监控图上出现“锯齿状”延迟曲线：每几秒一个尖峰，周期与
serverCron()执行频率（默认 10Hz）或淘汰强度强相关
为什么LATENCY HISTORY看不到eviction事件
常见原因不是配置遗漏，而是根本没触发淘汰路径：
- 当前
maxmemory-policy是noeviction，写失败直接返回错误，不走淘汰逻辑 -
used_memory_human远低于maxmemory，压测数据量不够或 key 被复用（如反复 set 同一个 key） - 用了
volatile-*策略，但所有 key 都没设EXPIRE，导致无候选键可删 - 阈值设得太高（如 100ms），而实际
eviction耗时在 3–8ms，全被过滤掉了
最稳妥的验证方式：先用 INFO memory 确认 evicted_keys 在增长，再查 LATENCY LATEST —— 如果前者动了后者没记录，基本可断定阈值设高了。
