maxmemory-samples仅对allkeys-lru和volatile-lru生效；设为5是多数场景起点，升至7可降热key误淘汰率约35%且延迟可控，超15会拖慢主线程，超200被静默截断为200；幂律分布场景应改用allkeys-lfu。

maxmemory-samples只在allkeys-lru和volatile-lru下起作用

设了maxmemory-samples却没看到淘汰行为变化？先查策略：CONFIG GET maxmemory-policy。如果返回的是noeviction、allkeys-random或volatile-ttl，这个参数压根不参与任何逻辑——它只在allkeys-lru和volatile-lru下被读取。很多人跳过这步直接调参，结果白忙一场。

从5调到7是多数场景的合理起点

默认maxmemory-samples 5在中等热度、生命周期较均匀的缓存里够用；实测升到 7 后，热 key 误淘汰率下降约 35%，且单次淘汰耗时仍在 0.1ms 内，P99 延迟基本不受影响。但再往上收益递减：

• maxmemory-samples 10：CPU 开销可能翻倍，高并发下淘汰延迟易突破 200μs
• maxmemory-samples > 15：在百万级 key 实例上，getSampleKey()调用本身会拖慢主线程，instantaneous_ops_per_sec常同步下跌
• maxmemory-samples > 200：Redis 启动或CONFIG SET时静默截断为 200，不报错也不警告

调大之前先确认你真需要LRU

如果业务存在明显幂律分布——比如 5% 的 key 承担 80% 请求，LRU 天然不适合：它只记“最后一次访问时间”，不记“访问频次”。这时maxmemory-samples再大也难救。更直接的解法是切策略：CONFIG SET maxmemory-policy allkeys-lfu（需 Redis 4.0+）。LFU 对冷热分层更鲁棒，而maxmemory-samples对它的作用也转向频次估算，逻辑完全不同。

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

线上调参必须盯住三个实时指标

别只看CONFIG GET返回值，关键看它是否真改变了淘汰质量：

• 观察 INFO stats 的keyspace_hits / (keyspace_hits + keyspace_misses)，若命中率不升反降，说明采样扩大后反而误伤了热 key
• 用redis-cli --stat盯evicted_keys和instantaneous_ops_per_sec的联动关系
• 执行redis-cli --latency或启用LATENCY DOCTOR，看淘汰毛刺是否加剧

真正容易被忽略的是：采样精度不是业务语义上的“正确性”杠杆，它撬动的是 CPU 和延迟预算——而这两项在高负载实例上往往比命中率更敏感。