maxmemory-samples这个参数到底影响力多大？我们先说下它的作用范围。简单来说，它只对`allkeys-lru`和`volatile-lru`这两种淘汰策略生效。如果你把策略配的是`allkeys-random`或`noeviction`，那这个参数就算设到200也完全不会参与任何逻辑。 很多团队调完参数就觉得“更准了”，结果一查`CONFIG GET maxmemory-policy`，策略根本没切过去。这件事在线上踩过坑的人太多了——调参数前先确认策略，是最基础的排查顺序。 ### 采样数从5调到10，CPU开销可能翻倍 每次内存淘汰触发时，Redis都会随机读取maxmemory-samples个key的lru字段（24位时间戳），然后比谁更老。这个操作不是O(1)，而是O(N)的扫描。来看具体数据： - 默认采样数5：单次淘汰通常小于0.05毫秒，基本无感 - 调到10：耗时涨到0.15~0.3毫秒，高并发场景开始堆积 - 调到50以上：在百万级key实例上，单次淘汰可能卡住主线程1~2毫秒 利用`INFO stats`观察时会发现，`evicted_keys`突增的同时，`instantaneous_ops_per_sec`经常同步下跌——这就是主线程被淘汰逻辑拖慢了。 所以别只盯着命中率，先盯`redis-cli --stat`里的`evicted`和`latency`毛刺。 ### 为什么设到200也没用？Redis会静默截断 这个参数最大只支持200。超出部分在启动时或`CONFIG SET`时会直接截断，而且不报错、不给任何提示。比如你执行： ```bash CONFIG SET maxmemory-samples 300 ``` 再查`CONFIG GET maxmemory-samples`，返回的依然是`200`。 线上调参数时，别相信你输的数值——一定要二次确认返回值。很多人吃了这个亏，一直以为自己设的是500，其实Redis早给悄悄掐掉了。 ### 真正需要调高的场景其实很窄坦白承认 坦白说，多数团队在这个参数上其实没什么可调的。你真的需要调高 maxmemory-samples的场景只有一个：冷热数据分离很极端，而且局部访问倾斜严重——比如一批冷数据的key长期无人问津，但因为采样太少总是被漏掉 但现实中更常见的问题是—LRU本身可能就不适合你的业务形态 - 如果热点集中在少数key上（幂律分布明显）`; allkeys-lfu往往比调大maxmemory-samples ]` -如果新key上线后立刻被高频访问，LRU天然会误杀它们。这时`lfu -log-factor和lfu -decay-time的作用比采样精度重要得多 -最后要提醒一点：` OBJECT IDLETIME返回的是秒级估算，本身挺粗糙的，别拿它来验证“哪个key真最老”，那结果不太可靠 采样精度不是万能杠杆——它撬动的主要是CPU资源和延迟开销，而不是业务语义上的“正确性”。调之前先问自己：你的问题到底是在淘汰策略上，还是在数据分布形态上？