memory purge 在大多数 redis 部署中完全无效，它不释放已删除 key 的内存，仅在启用 jemalloc 且 background_thread yes 的 redis 6.0+ 特定碎片场景下可能触发 arena 级 purge。
Redis 的 MEMORY PURGE 并不释放已删除 key 的内存
直接说结论：MEMORY PURGE 在大多数 Redis 部署中**完全无效**，它不会回收被 DEL、EXPIRE 或 LRU 驱逐后残留的内存。该命令仅对启用了 jemalloc 且配置了 background_thread yes 的 Redis 6.0+ 版本，在特定内存碎片场景下才可能触发 malloc_stats_print() 级别的内存归还——但依然不针对“已删除 key 的驻留内存”。
被删除 key 的内存到底什么时候释放？
Redis 使用惰性+定期两种策略清理内存，但释放行为受底层分配器和使用模式制约：
-
DEL命令执行后，key 对应的内存块只是从字典中解引用，实际内存是否归还给操作系统，取决于 jemalloc（默认）或 libc malloc 的内部策略 - jemalloc 默认不会立即把小块空闲内存交还 OS，而是缓存为“可用但未归还”状态，表现为
INFO memory中的mem_fragmentation_ratio> 1.0 且used_memory_rss远高于used_memory - 只有当 jemalloc 检测到大量连续空闲页（通常需数 MB 级别），并触发
purge操作时，才可能调用madvise(MADV_DONTNEED)归还——但这不是MEMORY PURGE控制的
真正能缓解内存滞留的操作有哪些？
如果你观察到 used_memory_rss 居高不下，而 used_memory 已明显下降，说明存在内存碎片。可尝试以下实操路径：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 确认是否真有碎片：运行
INFO memory，检查mem_fragmentation_ratio。若 > 1.5，且used_memory_rss−used_memory> 几百 MB，才值得干预 - 强制 jemalloc 主动 purge（仅限 jemalloc 编译版）：
MEMORY MALLOC-STATS可触发一次统计输出，部分版本会顺带触发轻量级 purge；更可靠的是向 Redis 进程发送SIGUSR1信号（kill -USR1 $(pidof redis-server)），这会强制 jemalloc 执行mallctl("arena.<i>.purge", ...)</i> - 重启是终极手段：对主从架构，可逐台
SLAVEOF NO ONE→CONFIG SET save ""→SHUTDOWN SAVE→ 启动新实例，避免 RDB 写入放大 RSS - 预防优于补救：避免频繁写入/删除大小悬殊的 value；用
SCAN+UNLINK替代KEYS+DEL；设置合理的maxmemory-policy（如allkeys-lfu）减少突发驱逐压力
MEMORY PURGE 为什么常被误解？
官方文档语义模糊，加上 Redis 7.0+ 引入了 MEMORY PURGE 命令，容易让人以为它是“内存清道夫”。但它的实际作用非常有限：
- 仅在 Redis 编译时启用了
jemalloc且运行时开启了activedefrag yes时，才可能触发 arena purge - 即使满足条件，它也只影响当前线程所属 arena，不保证全局生效；多次调用无叠加效果
- 在 Alpine Linux（musl libc）、macOS（system malloc）或禁用 jemalloc 的 Redis 上，该命令直接返回 OK 但什么都不做
- 错误日志里看不到任何提示，你无法判断它有没有起效
真正需要关注的是 mem_fragmentation_ratio 和 used_memory_peak，而不是迷信某个命令名里带 “PURGE” 就能解决问题。
