内存淘汰策略不释放物理内存，仅标记逻辑空闲，导致used_memory下降而used_memory_rss居高不下，mem_fragmentation_ratio>1.5即表明碎片严重；真正缓解需启用activedefrag、执行memory purge或重启进程。
不能。内存淘汰策略（maxmemory-policy）只决定“删哪些 key”，不负责“把释放的内存还给操作系统”——而内存碎片正是后者没做到导致的。
为什么淘汰 key 后内存 RSS 还居高不下？
Redis 删除一个 key 时，只是把对应的 redisObject 和底层数据结构（如 sds、dict）标记为可复用，并通知内存分配器（如 jemalloc）这块内存空闲了；但 jemalloc 通常不会立刻把这段内存归还给 OS，而是留作后续分配复用。这就造成 used_memory 下降了，used_memory_rss 却没同步下降，mem_fragmentation_ratio 拉高。
- 现象：执行
INFO memory发现mem_fragmentation_ratio > 1.5，但used_memory明显低于maxmemory - 本质：是内存分配器行为，不是 Redis 逻辑错误
- 影响：RSS 高 → 实际物理内存占用大 → 容易触发系统 OOM 或容器被 kill
真正能缓解内存碎片的配置和命令
淘汰策略本身不清理碎片，但以下手段可干预分配器行为或强制回收：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 启用自动碎片整理：
CONFIG SET activedefrag yes（Redis 4.0+），它会在空闲周期尝试合并小块空闲内存；需配合active-defrag-threshold-lower等参数调优 - 手动触发归还：
MEMORY PURGE（仅 jemalloc 支持），直接让分配器向 OS 交还所有可释放页 - 重启是最彻底方案：先
SHUTDOWN SAVE持久化，再重启进程 —— 新进程从零开始分配，碎片清零 - 避免频繁 resize：调小
hash-max-ziplist-entries等编码阈值，减少小对象反复扩容导致的内部碎片
淘汰策略选错反而加剧碎片问题
某些策略会加重分配器压力，间接恶化碎片：
-
volatile-random或allkeys-random：随机删除导致内存释放不连续，更难被分配器有效合并 -
volatile-ttl：集中淘汰临近过期的 key，可能在短时间内释放大量分散小内存块 - 对比之下：
allkeys-lfu或allkeys-lru因淘汰相对集中的冷数据，释放模式更规律，对碎片影响略小
碎片问题不在淘汰逻辑里，而在内存分配器与 OS 的交互层。盯着 maxmemory-policy 调来调去，解决不了 used_memory_rss 居高不下的根本症结。
