evicted_keys为0说明淘汰策略未触发；其单调递增需结合used_memory_peak和mem_fragmentation_ratio判断是否因碎片或峰值误淘汰；keyspace_misses不能直接反映淘汰效果，须依赖外部监控对比淘汰前后miss率变化。
INFO memory 和 INFO stats 里没有直接的“淘汰策略命中率”，但你能算出来——关键看 evicted_keys 和 keyspace_hits/keyspace_misses 的组合关系。
怎么看淘汰是否真的发生了
淘汰策略生效的前提是内存触达 maxmemory，而是否真有 key 被踢掉，得盯住 evicted_keys 这个指标：
- 如果
evicted_keys: 0，说明哪怕配置了allkeys-lfu，也没真正触发淘汰——可能是内存还够用，或者maxmemory没设（默认为 0，即不限制） -
evicted_keys单调递增 ≠ 健康：它只计数，不区分是 LFU 算错、还是大 Key 频繁写入挤占空间。要结合used_memory_peak和mem_fragmentation_ratio判断是不是内存碎片或峰值突刺导致的误淘汰 - 注意：从 Redis 6.2 开始，
evicted_keys仍只统计“因内存满被主动淘汰”的 key 数，不包含过期删除（那是expired_keys）
为什么不能直接用 keyspace_misses 算“淘汰命中率”
很多人误以为 keyspace_misses 高 = 淘汰策略没起作用，其实不是：
-
keyspace_misses包含所有未命中场景：缓存穿透（查根本不存在的 key）、缓存击穿（热 key 过期瞬间大量请求）、客户端压根没查缓存——和淘汰策略无关 - 真正反映淘汰副作用的是：淘汰后本该命中的 key 变成 miss。但 INFO 不提供这个细分维度，你得靠外部日志或监控对比（比如淘汰前后同一业务接口的 miss rate 变化）
- 更可靠的辅助指标是
instantaneous_ops_per_sec+evicted_keys的时间序列：如果每秒淘汰几百 key 的同时 QPS 暴涨，大概率是淘汰引发连锁 miss，而非单纯访问模式变化
LFU 策略下必须搭配 OBJECT FREQ 验证
Redis 6.2 修复了 LFU 计数器溢出问题，但不代表它自动“准”——你得手动验证高频 key 是否真被保留：
- 对疑似热点 key 执行
OBJECT FREQ key，观察数值是否随访问稳定增长（比如 5 分钟内从 10 → 15 → 18）。如果频繁卡在 63 不动，说明lfu-log-factor太小，或访问太稀疏 -
lfu-log-factor默认是 10，对大多数业务偏激进；若你发现冷 key 也很快涨到 10+，建议调低到 1–5；若只有极少数 key 能突破 20，可尝试调高到 50–100 - 别只看单次
OBJECT FREQ结果：LFU 是概率递增 + 对数衰减，需要持续观测节奏。突然归零？那可能是后台线程执行了LFUDecrAndReturn衰减，属于正常行为
真正容易被忽略的点是：evicted_keys 是累计值，不重置；一次误配 maxmemory 导致批量淘汰后，这个数字就永远大了——你得结合 uptime_in_seconds 和重启时间，判断当前周期内的实际淘汰量。
