redis内存碎片率持续大于1.5即需干预，须结合used_memory_rss与used_memory差值＞100mb确认真实碎片；activedefrag需同时满足active-defrag-ignore-bytes和active-defrag-threshold-lower双阈值才触发，仅开yes无效。
Redis内存碎片不是配置错误，而是jemalloc分配器与业务操作共同作用的结果；只要看到mem_fragmentation_ratio持续大于1.5，就说明碎片已开始影响可用内存。
怎么看碎片是否真实存在
别只看top或ps的RSS值——它包含所有已分配但未归还的内存，含碎片。真正要看的是redis-cli INFO memory输出中的三个关键字段：
-
used_memory：Redis实际存储数据占用的字节数（不含碎片） -
used_memory_rss：操作系统给Redis进程分配的物理内存总量 -
mem_fragmentation_ratio=used_memory_rss/used_memory，该值>1.5即需干预，>2.0通常已导致OOM风险
注意：used_memory_rss远大于used_memory≠内存泄漏，大概率是碎片堆积；如果删了大量key后used_memory_rss不降，基本可锁定为外部碎片问题。
为什么activedefrag yes开了却没效果
自动碎片整理不是“开就完事”，它有明确的双阈值触发机制，缺一不可：
-
active-defrag-ignore-bytes 100mb：单个空闲块小于100MB时忽略（避免小碎片反复搬运） -
active-defrag-threshold-lower 10：当前碎片率低于10%时不启动（默认值是10，单位是百分比，不是小数） - 两者必须同时满足才触发整理；常见错误是只调
activedefrag yes，却没设active-defrag-threshold-lower，导致阈值仍为默认10，而生产环境碎片率常卡在1.6~1.8之间，永远不触发
建议初调值：active-defrag-threshold-lower 5（对应5%碎片率），active-defrag-ignore-bytes 50mb，再配合active-defrag-cycle-min 25保障最低CPU投入。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
MEMORY PURGE执行失败的常见原因
MEMORY PURGE命令依赖jemalloc的mallctl接口，不是所有编译版本都支持：
- 确认Redis是否用jemalloc编译：
redis-cli INFO memory中查看mem_allocator字段，必须为jemalloc（libc/tcmalloc不支持） - 某些容器镜像（如Alpine版）默认用musl libc，即使指定
MALLOC=jemalloc也常因链接问题失效 - 执行后无报错但
used_memory_rss不变？检查jemalloc.prof是否启用——未启用时MEMORY PURGE可能静默跳过
安全做法：先在测试实例运行redis-cli --raw MEMORY PURGE，再立刻查INFO memory，若used_memory_rss未下降，说明底层不支持，别在线上强推。
哪些操作会加速碎片积累
碎片不是凭空产生，而是由具体命令模式放大：
-
APPEND频繁追加字符串：每次扩容都可能触发新内存块分配，旧块残留成内部碎片 - 大量
SET+ 短TTL（如EXPIRE key 60）：到期集中删除造成外部碎片爆发 - 混合存储大小悬殊的value：比如同一DB里既有1KB的token，又有10MB的用户画像，jemalloc无法复用不同档位的空闲块
- 禁用ziplist编码（如
hash-max-ziplist-entries 0）：小Hash直接转为dict，内存分配粒度变大，碎片率翻倍
最隐蔽的坑：用HSET存千级字段的Hash，却不设hash-max-ziplist-entries，表面省事，实则每字段都独立分配内存，碎片增长速度远超预期。
碎片治理没有银弹——activedefrag治标，数据结构和生命周期设计才治本。最容易被忽略的一点：碎片率低不等于内存健康，used_memory_rss接近容器memory limit时，哪怕mem_fragmentation_ratio只有1.3，一次大key写入也可能直接OOM。
