内存碎片率>1.5是首要排查点，需结合used_memory_rss与used_memory差值>100MB判断是否真需干预；确认后启用activedefrag yes并调优四参数，配合长期数据结构优化与过期分散。
内存碎片率 > 1.5 是首要排查点
Redis删除键后内存没释放，十有八九不是数据没删，而是内存碎片卡住了。用 redis-cli INFO MEMORY 查 mem_fragmentation_ratio：如果大于 1.5，说明 jemalloc 分配器手里有一堆零散小块，没法合并给新数据用。
临时缓解可开启主动碎片整理：CONFIG SET activedefrag yes，并调高整理强度：CONFIG SET active-defrag-threshold-lower 10（默认是 10%，建议设为 5–15）、CONFIG SET active-defrag-cycle-min 25（默认 5，设高些让后台更积极）。但注意：整理过程会消耗 CPU，别在业务高峰开。
- 该功能 Redis 4.0+ 才支持，老版本只能重启实例
- 启用后观察
active_defrag_running和mem_fragmentation_ratio是否下降 - 若碎片率长期 > 2.0，且
used_memory_rss远高于used_memory，说明碎片已严重阻塞回收
expired_keys 增长缓慢或停滞
你删了 key，但 INFO stats 里 expired_keys 几乎不动，说明过期键没被真正清理——Redis 的定期删除是每 100ms 随机抽查 20 个 key，漏掉大量过期项很常见，尤其当 key 总量大、过期集中时。
不要依赖自动清理。对已知大批量过期的场景，直接手动触发：SCAN 0 COUNT 1000 分批查 key，再对 TTL 返回 -1 或很小的 key 批量执行 EXPIRE 或 DEL；更稳妥的是用 redis-cli --bigkeys 先扫出疑似残留的大 key，再针对性处理。
-
TTL key返回 -1 表示没设过期时间，-2 表示 key 不存在或已过期但未被惰性/定期删除 - 避免在生产环境用
KEYS *，它会阻塞主线程 - 如果大量 key TTL 为 -1，说明业务写入时根本没设过期，这是设计缺陷，得改代码
客户端输出缓冲区无声膨胀
看起来没写数据，内存却稳升？检查慢订阅客户端或异常连接。Redis 会给每个 client 分配输出缓冲区，一旦客户端不及时读取（比如 PUB/SUB 消费端卡住、网络抖动），缓冲区就会越积越大，且不会计入 used_memory，只体现在 used_memory_rss 里。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
用 CLIENT LIST 查 omem 字段（output buffer memory），筛选出 omem > 1MB 的连接；重点关注 pubsub 类型和 idle 时间超长的 client。强制踢掉：CLIENT KILL ID <id>。
- 预防措施：配置
client-output-buffer-limit pubsub（如32mb 8mb 60），超限自动断连 - 监控项：关注
clients_blocked和blocked_clients是否异常升高 - 集群模式下，主节点的复制缓冲区（
repl-backlog-size）过大也会吃内存，别设成几 GB
大 Key 删除后内存仍不释放
删掉一个 500MB 的 ZSET，内存半天不降？因为 Redis 删除大结构是“懒释放”：先标记删除，后台异步回收。期间 used_memory 已扣减，但 used_memory_rss 还挂着旧内存块，直到分配器真正归还。
验证方式：删完立刻跑 INFO MEMORY，看 used_memory 是否下降（逻辑内存已释放），再等 1–2 分钟看 used_memory_rss 是否同步下降。若不降，结合前面几点排查碎片或缓冲区。
- 大 Key 必须拆分，别等它变大再处理；用
redis-cli --bigkeys定期扫描（生产环境建议低峰执行） - 哈希、列表、集合类结构，单 key 元素数超过 1k 就该警惕，超过 1w 基本算危险信号
- 删除前用
MEMORY USAGE key确认真实大小，避免误判
真正难处理的永远不是“怎么删”，而是“为什么删了看不见效果”——碎片、缓冲区、懒释放这三者常互相掩盖。先盯死 mem_fragmentation_ratio 和 used_memory_rss 的差值，比盲目调策略管用得多。
