maxmemory-samples设为5是多数场景兼顾速度与准确性的合理起点，设为7能提升LRU/LFU淘汰精度但增加延迟，需根据key生命周期分布和淘汰压力权衡选择。
调大 maxmemory-samples 能提升淘汰精度，但不等于性能更好；实际效果取决于淘汰策略、数据访问模式和 CPU 承载能力。
为什么 maxmemory-samples 值会影响淘汰行为
Redis 在触发内存淘汰（比如 allkeys-lfu 或 volatile-lru）时，并不会遍历全部 key，而是从当前数据库中随机采样 maxmemory-samples 个键，再从中选出“最该淘汰”的那个。这个采样过程是近似算法的核心环节：
- 值为
3：每次只看 3 个键，淘汰快、CPU 开销小，但容易误删刚被访问过的热点 key - 值为
10：样本更广，LFU 频次统计或 LRU 时间估算更稳，缓存命中率通常更高 - 值 >
15：抽样本身开始成为瓶颈，evict.c中的getSampleKey()调用耗时明显上升，可能拖慢写入响应
Redis 6.0 下推荐的取值与对应场景
Redis 6.0 默认仍是 maxmemory-samples 5，但它对 LFU 的衰减逻辑做了优化，使得更高采样值的收益更明显。结合线上实测反馈：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 缓存命中率持续低于 85%，且业务有明显热点（如商品详情页、用户画像）→ 尝试设为
8或10 - 写入延迟毛刺多，
INFO stats显示evicted_keys_per_sec波动剧烈 → 先降为3观察是否平滑，再逐步回调 - 使用
volatile-ttl策略 →maxmemory-samples几乎无影响（TTL 淘汰不依赖采样，只比对过期时间） - 启用了
active-defrag且内存碎片率 > 20% → 避免把maxmemory-samples设太高，否则 CPU 会同时扛采样 + 碎片整理双重压力
怎么验证调整是否真的有效
不能只看 CONFIG GET maxmemory-samples 返回了新值，关键要看它是否改变了淘汰质量：
- 执行
CONFIG SET maxmemory-samples 8后，用INFO stats持续观察evicted_keys增速是否变缓、keyspace_hits / keyspace_misses比值是否上升 - 对比调整前后相同压力下的
latency doctor输出：redis-cli --latency -h x.x.x.x，重点关注 P99 延迟是否收窄 - 如果业务侧监控到后端 DB 查询量下降，基本可确认 LFU/LRU 淘汰更准，保住了真正需要的 key
真正难的是平衡：采样越多，单次淘汰越准，但每秒能完成的淘汰次数可能下降；尤其在突发写入高峰，宁可让精度稍低，也要保证淘汰动作不卡住主线程。生产环境别直接改配置文件，先用 CONFIG SET 测试 15 分钟，盯着 used_cpu_sys 和 evicted_keys_per_sec 两个指标再决定是否固化。
