maxmemory-samples仅对allkeys-lru和volatile-lru策略生效；设为5~7可平衡误淘汰率与延迟，超15会拖慢主线程；调参前须确认淘汰策略，幂律分布场景应改用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 延迟基本不受影响。但再往上收益递减：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
maxmemory-samples 10：CPU 开销可能翻倍，高并发下淘汰延迟易突破 200μs -
maxmemory-samples > 15：在百万级 key 实例上，getSampleKey()调用本身会拖慢主线程，instantaneous_ops_per_sec常同步下跌 -
maxmemory-samples > 200：Redis 启动或CONFIG SET时静默截断为 200，不报错也不警告
线上调参必须盯住三个实时指标
别只看 CONFIG GET 返回值，关键看它是否真改变了淘汰质量：
- 用
redis-cli --stat观察evicted增速是否变缓、节奏是否更稳 - 跑
redis-cli --latency -h x.x.x.x，重点盯 P99 延迟是否收窄，而非平均值 - 查
INFO stats的keyspace_hits / (keyspace_hits + keyspace_misses)，若命中率不升反降，说明采样扩大后反而误伤了热 key
比调 samples 更重要的事：确认你真需要 LRU
如果业务存在明显幂律分布——比如 5% 的 key 承担 80% 请求，LRU 天然不适合：它只记“最后一次访问时间”，不记“访问频次”。这时 maxmemory-samples 再大也难救。更直接的解法是切策略：CONFIG SET maxmemory-policy allkeys-lfu（需 Redis 4.0+）。LFU 对冷热分层更鲁棒，而 maxmemory-samples 对它的作用也转向频次估算，逻辑完全不同。
