memory purge 不是淘汰策略，仅合并空闲内存块以降低碎片率；它不删数据、不释放有效键内存，只向jemalloc发起内存归并请求，使mem_fragmentation_ratio趋近1.0～1.2，used_memory不变而used_memory_rss可能下降。
MEMORY PURGE 不是淘汰策略，它不删数据、不释放有效键占用的内存，只合并空闲内存块；想靠它解决 maxmemory 触发的 OOM，基本没用。
MEMORY PURGE 的真实作用：只整理碎片，不释放业务内存
这个命令本质是向底层内存分配器（如 jemalloc）发起一次“内存归并”请求，让分配器把零散的空闲页重新整合成连续大块，再交还给操作系统。它不会触发任何 key 的删除、过期检查或淘汰逻辑。
-
MEMORY PURGE执行后，used_memory不变，used_memory_rss可能下降，mem_fragmentation_ratio会趋近于 1.0～1.2 - 对
evicted_keys、expired_keys等指标无影响——它完全绕过 Redis 的键生命周期管理 - 仅在使用
jemalloc（Redis 默认）时生效；若编译时用了libc malloc或glibc malloc，该命令直接返回错误(error) ERR MEMORY PURGE not supported
和 maxmemory 淘汰策略的根本区别
淘汰策略（如 allkeys-lru）是在内存真正不够用时，主动挑选并删除部分 key，从而降低 used_memory；而 MEMORY PURGE 是在 used_memory 没超限、但 used_memory_rss 虚高时，专治“操作系统看得见、Redis 用不上”的那部分内存。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 场景对比：
mem_fragmentation_ratio = 2.3且used_memory = 2GB→ 实际 RSS 占用约 4.6GB，但 Redis 只“认为”自己用了 2GB。此时MEMORY PURGE可能释放出 1GB+ RSS；而淘汰策略根本不会触发，因为还没到maxmemory - 副作用差异：淘汰策略会丢数据，可能引发客户端缓存穿透；
MEMORY PURGE是纯内存整理，无业务影响，但会短暂阻塞主线程（通常几毫秒到几十毫秒） - 触发时机：淘汰策略由写入命令自动触发；
MEMORY PURGE必须手动执行或通过脚本定时调用
什么时候该用 MEMORY PURGE？看这三个信号
别等 mem_fragmentation_ratio > 1.5 才想起来——碎片积累有滞后性，等它飙到 2.0+，往往说明已经持续数天未干预。
-
INFO memory中mem_fragmentation_ratio≥ 1.4，且近期没有大规模 key 过期或淘汰（evicted_keys和expired_keys增长缓慢） - 系统监控显示 Redis 进程 RSS 持续高于
used_memory × 1.3，但used_memory本身平稳 - 集群中某节点因 RSS 过高被容器平台 OOM kill，而其他同规格节点
used_memory相近却没事——大概率是该节点碎片更严重
执行前必须确认的三件事
盲目执行 MEMORY PURGE 不但无效，还可能暴露配置或环境问题。
- 先运行
INFO memory，确认输出里包含mem_allocator:jemalloc-5.2.1（或类似 jemalloc 版本），否则命令无效 - 避免在主从复制高峰期执行——虽然不改数据，但主线程阻塞可能导致
repl_backlog积压或从库延迟突增 - 生产环境建议加
--raw参数用 redis-cli 执行，并捕获返回值：redis-cli --raw MEMORY PURGE | grep -q "OK" || echo "purge failed"，失败时不报错，只静默返回空行
碎片不是“删点东西就能好”的问题，它是内存分配器和操作系统协同行为的结果；MEMORY PURGE 是个精准手术刀，但得知道切哪、为什么切——否则容易误判成“Redis 内存泄漏”或者反复重启白忙活。
