memory stats 返回 redis 内存分配各环节的详细统计项，包括键空间、客户端缓冲区、aof 缓冲区、lua 脚本内存、复制积压缓冲区等，以键值对（redis 7.0+ 为嵌套数组）形式呈现，字段如 db.0.keys、used_memory_dataset、used_memory_overhead 等，单位均为字节。
memory stats 返回的是什么数据
MEMORY STATS 是 Redis 4.0+ 提供的诊断命令，它不返回总内存用量，而是拆解出内存分配各环节的统计项，比如键空间、客户端缓冲区、AOF 缓冲区、Lua 脚本内存、复制积压缓冲区等。它的输出是键值对形式的 map（Redis 7.0+ 改为数组嵌套结构），每项都有明确语义，但字段名带点号（如 db.0.keys）、部分字段含义容易误解（比如 peak.allocated 是进程启动以来峰值，不是当前）。
执行方式很简单：
redis-cli MEMORY STATS或在 redis-cli 中直接输入
MEMORY STATS。注意：该命令需要管理员权限，普通只读用户无法执行。
哪些字段真正反映业务键的内存开销
真正和你存的 key-value 直接相关的字段只有两类：db.X.keys、db.X.expires（X 是数据库编号），它们分别表示该 db 中键数量和带过期时间的键数量；但这些只是计数，不体现字节占用。实际键空间内存消耗藏在 db.X.avg_ttl（平均剩余 TTL，间接反映过期策略压力）和更底层的 used_memory_dataset 里 —— 后者才是所有键值数据 + 底层编码结构（如 dict、ziplist、intset）实际占用的内存，不含 Redis 自身开销。
-
used_memory_dataset≈ 你所有 key 的 value 内容 + key 字符串 + Redis 内部元数据（如 dictEntry、robj） -
used_memory_overhead是 Redis 运行必需的“固定成本”，包括客户端输出缓冲、复制缓冲、Lua 占用、连接结构体等 - 如果
used_memory_overhead占比突然升高（比如 >30%），大概率是某个客户端缓冲区失控（如订阅了大流量 channel 却消费慢）或存在大量空闲连接
对比 memory usage 和 memory stats 的适用场景
MEMORY USAGE <key></key> 查单个 key 的估算内存，适合排查热点 key；而 MEMORY STATS 是全局快照，适合判断内存分布是否健康。两者互补，不能互相替代。
- 查大 key？用
MEMORY USAGE配合SCAN脚本，别指望MEMORY STATS给出 key 名 - 发现
used_memory_dataset持续增长但 key 数不变？说明 value 在变大（如 APPEND 日志、LPUSH 增长列表），或编码退化（如 ziplist 扩容成 skiplist） - 发现
clients_output_buffer_memory异常高？立刻用CLIENT LIST找omem值大的连接，通常是 PUB/SUB 消费延迟或 MONITOR 客户端没关
容易被忽略的兼容性与精度问题
MEMORY STATS 在 Redis 6.0 之前不包含 active_defrag 相关字段，在 7.0+ 中新增了 defrag_hits、defrag_misses 等项，但仅当启用了 activedefrag yes 且内存碎片率（mem_fragmentation_ratio）> 1.5 时才有意义。另外，所有数值单位都是字节，但部分字段（如 allocator.allocated）取决于编译时选择的内存分配器（jemalloc vs libc），不同分配器下 used_memory 和 allocator.allocated 的差值可能达 10%~20%，这不是 bug，是内存管理机制差异。
最常被跳过的动作：运行 INFO memory 对比看 mem_fragmentation_ratio。如果这个值 > 1.5，MEMORY STATS 里的 allocator 子项才值得深挖；否则优先看 used_memory_dataset 和 used_memory_overhead 的比例变化。
