volatile-lru仅淘汰显式设置过期时间的键，对未设ttl的键完全无效；若存在大量永不过期键，内存将持续增长至oom，且evicted_keys恒为0。
volatile-lru 不会淘汰没设过期时间的 Key，如果业务写入大量永不过期键，淘汰策略完全不生效，内存必然持续上涨直至溢出。
volatile-lru 的真实作用范围
这个策略只对 EXPIRE、SETEX 或 SET 带 EX 选项设置过期时间的键生效。所有未显式设置 TTL 的键——哪怕你用 SET key value 直接写入——都会被 volatile-lru 完全忽略。
- 执行
redis-cli config get maxmemory-policy确认当前确实是volatile-lru - 用
redis-cli --scan --pattern "*"配合TTL key批量检查，会发现大量返回-1（永不过期）或-2（key 不存在） -
INFO memory中的used_memory持续增长，但evicted_keys始终为 0，就是最直接的证据
如何快速定位“伪缓存”永不过期键
这类键常伪装成缓存（比如命名含 cache:、tmp:），实际却从不设过期，久而久之撑爆内存。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 用
redis-cli --bigkeys找出体积最大的几个键，再用MEMORY USAGE key和TTL key分别验证其大小与存活状态 - 扫描高频前缀：
redis-cli --scan --pattern "cache:*" | xargs -L 1 -I {} sh -c 'echo {}; redis-cli ttl {}' - 若日志中频繁出现
OOM command not allowed when used memory > 'maxmemory'错误，且evicted_keys为 0，基本可锁定是永不过期键泛滥
修复时别只改策略，先清理再切换
直接把 maxmemory-policy 改成 allkeys-lru 能让淘汰立刻生效，但旧的永不过期键仍占着内存，新写入可能马上又触发 OOM。
- 优先执行清理：用
SCAN+DEL清掉明确废弃的永不过期键，例如redis-cli --scan --pattern "temp:*" | xargs -r redis-cli del - 再动态切换策略：
CONFIG SET maxmemory-policy allkeys-lru（注意：该操作不保存到配置文件，需后续CONFIG REWRITE或手动更新redis.conf） - 上线前强制校验：所有写入逻辑必须显式携带
EX或调用EXPIRE，禁止裸SET
真正容易被忽略的是：即使启用了 allkeys-lru，如果某类键被高频访问（比如用户 session hash），它可能永远进不了淘汰队列——这时得结合 MEMORY USAGE 和业务语义判断是否该拆分或降级存储。
