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和延迟，而不是业务语义上的“正确性”。