Redis淘汰策略不直接处理大Key，仅在内存超限时按策略选择待删key；大Key是否被删取决于是否被选中，而非体积大小。
大Key本身不会被“淘汰策略”直接处理
Redis的maxmemory-policy（如allkeys-lfu、volatile-lru等）只决定“该删哪个key”，不判断key是不是大。哪怕一个String占50MB，只要它没被选中淘汰，就一直留在内存里。真正触发删除的，是写入新数据时内存超限 + 淘汰策略生效的组合动作——不是“因为它是大Key所以删”，而是“刚好轮到它被选中，且它又恰好是个大Key”。
选错淘汰策略会让大Key更难被清理
比如你用了volatile-ttl，但大Key根本没设过期时间（TTL为-1），那它永远进不了候选池；又比如用noeviction（默认策略），内存满了直接报错(error) OOM command not allowed when used memory > 'maxmemory'.，大Key不仅不删，连新写入都卡住。
-
volatile-*类策略对无TTL的大Key完全无效 -
allkeys-lru可能保留冷的大Key（比如一次写入后长期不访问，但体积巨大） -
allkeys-lfu对低频但体积大的Key也不友好——访问少≠该删，尤其当它偶尔被读一次就拉高频率计数
真正能缓解大Key内存压力的实操动作
淘汰策略只是兜底手段，不能替代主动治理。以下操作才直接影响大Key的内存占用：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 用
redis-cli --bigkeys定期扫描，定位String> 1MB 或Hash/Set> 1万成员的key - 对已确认的大Key，改用渐进式删除：
UNLINK代替DEL（把删除异步化，避免阻塞） - 拆分逻辑必须落地：比如把一个存用户全部订单的
orders:uid123，按月拆成orders:uid123:202606、orders:uid123:202607 - 压缩value再存：对JSON类
String，入库前用Snappy或zstd压缩，取用时解压——注意CPU开销权衡
配置和监控必须配套做
光调maxmemory-policy没用。得让淘汰真正起效：
- 确保
maxmemory已设置（默认是0，即不限制），否则淘汰策略根本不触发 - 检查
INFO memory输出中的used_memory_rss/used_memory比值，若>1.5说明内存碎片严重，MEMORY PURGE或重启更有效 - 观察
evicted_keys指标是否持续增长——如果为0，说明要么没超限，要么策略选错，要么根本没配maxmemory
大Key的麻烦不在“能不能删”，在于“删的时候会不会卡住整个实例”。淘汰策略解决不了卡顿，只能决定删谁；真正要动手的，是拆、压、异步删这三件事。
