noeviction仍是Redis 6.0+默认淘汰策略，升级不会自动切换；但若redis.conf中maxmemory-policy被注释或缺失，启动将fallback至noeviction，且maxmemory必须显式设置才能使策略生效。
noeviction 仍然是 Redis 6.0+ 的默认淘汰策略，升级本身不会自动切换策略——你原来的 maxmemory-policy 配置值不变，除非手动改。
Redis 6.0+ 淘汰策略列表没变，但 LFU 实现更稳了
八种策略（allkeys-lru、volatile-lfu 等）在 4.0 就已齐备，6.0 并未新增或删减。变化在于：LFU 计数器的衰减逻辑和采样精度被优化，对“短期刷量干扰”更鲁棒。比如原来一次突发访问可能把冷 key 推高计数，现在默认每分钟衰减一次（lfu-decay-time 1），且计数上限从 255 改为可配置（lfu-log-factor 影响增长斜率）。如果你没调过这些参数，升级后行为会更符合真实访问热度。
升级后 CONFIG GET maxmemory-policy 返回值可能意外变成 noeviction
这不是策略变了，而是配置丢失了：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 旧版 Redis（如 5.x）允许在
redis.conf中写maxmemory-policy allkeys-lru，但若该行被注释或文件被覆盖，启动时就 fallback 到默认值 - 6.0+ 启动日志里会明确打印
maxmemory-policy set to 'noeviction'，容易误以为“升级导致变更” - 检查方法：运行
redis-cli CONFIG GET maxmemory-policy，再对比你的redis.conf是否真有这行且未被注释
别忽略 maxmemory 仍需显式设置
无论哪个版本，只要 maxmemory 是 0（即未设上限），淘汰策略就完全不生效——哪怕你配了 allkeys-lru，内存涨到宿主机 OOM Killer 都不会触发淘汰。升级后常见坑是：
- Docker 部署时只设了
-m 2g，但没在redis.conf里配maxmemory 1536mb（留出缓冲） - K8s Pod 内存 limit 为 2Gi，但
maxmemory设成2gb，导致 fork RDB 时因maxmemory-reserved缺失而失败 - 用
CONFIG SET maxmemory 1gb临时生效，但没写回 conf，重启后还原
maxmemory + maxmemory-policy 两个配置同时存在且非默认值。升级只是放大了旧配置里原本就存在的盲区。 
