config set maxmemory-policy无需重启即可生效，因其仅原子更新全局变量server.maxmemory_policy，毫秒级完成且不触发淘汰；真正执行淘汰需同时满足used_memory≥maxmemory和有新写入命令两个条件。
CONFIG SET maxmemory-policy 不需要重启，但必须满足前提条件才能真正生效。
为什么 CONFIG SET maxmemory-policy 不用重启也能改？
Redis 把淘汰策略存在全局变量 server.maxmemory_policy 里，CONFIG SET 只是原子性地更新这个值，毫秒级完成，不扫描 key、不触发任何淘汰动作。所以：
✅ 写命令立刻返回 OK
✅ 配置变量即时变更（config get maxmemory-policy 能立刻看到新值）
❌ 不会主动删数据，也不会影响当前已存在的 key
改完策略后为什么没看到 key 被淘汰？
新策略只在两个条件**同时满足**时才实际执行淘汰：
• used_memory ≥ maxmemory（内存已达上限）
• 有新的写入命令被执行（如 SET、HSET、LPUSH 等带 CMD_DENYOOM 标志的命令）
也就是说，即使你刚切到 allkeys-lru，只要没新写入、或者内存还没打满，evicted_keys 计数器就永远是 0。
常见误判场景：
• 切完策略立刻查 INFO memory，发现 evicted_keys:0 就以为没生效
• 内存使用率只有 70%，却期待 LRU 开始清理
• 用 DEL 或 GET 测试，这些命令不触发淘汰逻辑
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
线上操作前必须检查的三件事
- 确认
maxmemory已设置且非 0：执行config get maxmemory，返回值应为具体字节数（如"1073741824"），不是"0"；否则淘汰机制压根不启动 - 确认当前内存已接近上限：用
INFO memory查看used_memory_human和maxmemory_human，差值小于 50MB 才算“临界” - 同步修改配置文件：
CONFIG SET是运行时修改，Redis 重启后会回落到redis.conf中的值，务必立刻编辑配置文件并保存，避免意外重启导致策略回退
noeviction 切到其他策略时的特殊风险
如果原策略是 noeviction，而内存早已超限，那么切策略瞬间不会释放内存，但**下一次写入就会直接触发淘汰**——这可能引发意料之外的 key 丢失，尤其当业务没做好缓存穿透/击穿防护时。
更危险的是：
• 若选了 volatile-ttl，但大部分 key 没设过期时间，实际可淘汰的 key 极少，写入仍大概率报错 OOM command not allowed when used memory > 'maxmemory'
• 若选了 allkeys-random，淘汰完全不可控，可能删掉高频热 key
建议线上切换前先用 redis-cli --scan --pattern "*" + ttl 批量探查 key 的过期分布，再决定是否适合用 volatile-* 类策略。
OK，要看 INFO stats 里的 evicted_keys 是否开始增长，以及业务写请求是否不再报 OOM 错。
