activedefrag yes无效是因为它非后台常驻线程，仅在主线程空闲且同时满足active-defrag-ignore-bytes≥100mb、active-defrag-threshold-lower≥12（即碎片率≥1.12）、mem_allocator为jemalloc时才触发整理。
只执行 CONFIG SET activedefrag yes 是无效的，它几乎从不真正开始整理。
为什么 activedefrag yes 开了却没反应
Redis 的 activedefrag 不是常驻后台线程，它只在主线程空闲时“抽空干活”，且必须同时满足两个硬性阈值才触发：
-
active-defrag-ignore-bytes：碎片绝对值 ≥ 当前设置（默认100mb），否则直接跳过 -
active-defrag-threshold-lower：碎片率 ≥ 当前设置（默认10，即 1.10 倍，不是 10%！注意单位是百分比 ×10） - 主线程 CPU 必须有空闲——QPS 长期 >15k 或 CPU 持续 >90%，
active_defrag_running就一直是 0 -
mem_allocator必须是jemalloc（libc下开了也白开）
四个关键参数怎么设才真正生效
这四个参数必须一起调，漏一个就等于没开：
-
activedefrag yes：总开关，注意是yes，不是on -
active-defrag-ignore-bytes 100mb：低于 100MB 碎片不启动，防小碎屑反复调度 -
active-defrag-threshold-lower 12：碎片率 ≥1.12（即 12%）就更早响应，比默认 10 更敏感 -
active-defrag-cycle-min 100、active-defrag-cycle-max 500：单次至少抢 100ms，上限压到 500ms，避免“蜻蜓点水”或卡顿
验证是否生效：redis-cli INFO memory | grep -E "active_defrag|mem_fragmentation"，重点看 active_defrag_hits 是否缓慢上涨。
集群环境下最容易被忽略的坑
Redis Cluster 节点之间完全不共享配置，CONFIG SET 只对当前连接节点生效，重启即丢失：
- 每个 master 和 slave 节点都必须单独执行完整配置命令
- 生产环境务必写入各节点的
redis.conf并CONFIG REWRITE持久化 - 别信“配一个节点，其他自动同步”——这是常见误判来源
什么时候其实不该开 activedefrag
不是所有高碎片都需要干预：
mem_fragmentation_ratio ：OS 已开始 swap，优先查内存不足或 <code>maxmemory过小1.0 ：正常波动，尤其 <code>used_memory-
mem_fragmentation_ratio > 1.5但used_memory_rss - used_memory ：绝对碎片量太小，整理收益远低于开销
真正要动手的信号只有一个：mem_fragmentation_ratio > 1.5 且 used_memory_rss - used_memory > 100mb。其余都是干扰项。
