maxmemory-samples仅对allkeys-lru和volatile-lru淘汰策略生效，若配置为allkeys-random或noeviction则完全不参与逻辑；其值增大虽提升采样精度，但CPU开销线性增长，单次淘汰耗时随采样数增加而上升。
maxmemory-samples到底影响谁？只对allkeys-lru和volatile-lru生效
设了maxmemory-samples 100但淘汰行为没变化？先查CONFIG GET maxmemory-policy。如果返回的是allkeys-random或noeviction，这个参数完全不参与任何逻辑——它只在allkeys-lru和volatile-lru策略下被读取。很多人调完就以为“更准了”，结果策略根本没切过去。
采样数从5调到10，CPU开销可能翻倍
每次内存触发淘汰时，Redis要随机读取maxmemory-samples个key的lru字段（24位时间戳），再做比较。这不是O(1)，而是O(N)扫描成本：
- 默认
maxmemory-samples 5：单次淘汰通常 - 设为
10：耗时约0.15–0.3ms，高并发下易堆积 - 设为
50以上：在百万级key实例上，单次淘汰可能卡住主线程1–2ms，INFO stats里evicted_keys突增时，instantaneous_ops_per_sec常同步下跌
别只盯着命中率，先盯redis-cli --stat里的evicted和latency毛刺。
为什么设到200也没用？Redis会静默截断
maxmemory-samples最大只支持200，超出值会被启动时或CONFIG SET时直接截断，且不报错、不警告。比如你执行：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
CONFIG SET maxmemory-samples 300
再CONFIG GET maxmemory-samples，返回的仍是200。线上调参时，别信自己输的数，一定要二次确认返回值。
真正需要调高的场景其实很窄
调大maxmemory-samples只在一种情况明显受益：冷热分离严重 + 局部访问倾斜（比如一批冷数据长期不被访问，但因采样太少总被漏掉）。但更常见的问题是——你的数据压根不适合LRU：
- 如果热点集中在少数key（幂律分布），
allkeys-lfu往往比调maxmemory-samples有效得多 - 如果新key上线后立刻被高频访问，LRU天然误杀，这时
lfu-log-factor和lfu-decay-time比采样精度更重要 -
OBJECT IDLETIME返回的是秒级估算，本身不准，别拿它验证“哪个key真最老”
采样精度不是万能杠杆，它撬动的是CPU和延迟，而不是业务语义上的“正确性”。
