MEMORY USAGE 是 Redis 7 最直接可靠的单 key 内存评估方式，但包含元数据、编码开销、指针及哈希表扩容冗余等全部占用，不区分是否过期，也不反映共享内存或 AOF/RDB 缓冲区。
MEMORY USAGE 是 Redis 7 中最直接、最可靠的单 key 内存评估方式，但它返回的不是“数据本身大小”，而是包含元数据、编码开销、指针、哈希表扩容冗余等在内的完整内存占用。盲目依赖它做容量预估，容易低估真实压力。
为什么 MEMORY USAGE 比 --bigkeys 更准，但又不能全信
redis-cli 的 --bigkeys 只统计 key 名 + value 序列化后粗略估算值（比如对 hash 只采样几个 field），不计入 dict 扩容冗余、编码切换开销、过期时间存储等；而 MEMORY USAGE 是运行时真实分配量，由 Redis 内存分配器（如 jemalloc）实际返回，含所有管理开销。
- 对一个 10 万字段的
HASH，--bigkeys可能报 “~2MB”，但MEMORY USAGE实测可能达 8–12MB（因 dict 扩容到 262144 桶，每个桶指针 + entry 结构体叠加） -
MEMORY USAGE不区分是否过期：已过期但尚未被惰性/定期删除的 key，仍会计入 - 它不体现共享内存（如 refcount > 1 的字符串对象），也不反映 AOF/RDB 缓冲区临时占用
执行 MEMORY USAGE 前必须确认的三件事
该命令在高并发或大 key 场景下可能阻塞主线程（尤其对 LIST/SET/HASH 类结构），Redis 7 虽优化了部分遍历逻辑，但无法完全避免。
- 确保目标 key 存在且类型明确——对不存在的 key 返回
0，容易误判为“空” - 避免在生产高峰期间批量执行：一次查 100 个大 key，可能引发
latency spikes，可用SLOWLOG GET验证是否触发慢日志 - 注意 client 输出缓冲区限制：
client-output-buffer-limit normal若设得太小，大结果可能被强制断连
MEMORY USAGE 在 Redis 7 中的典型误用场景
很多人用它验证“压缩是否生效”，比如把 string 改成 ziplist 编码的 hash，却发现 MEMORY USAGE 反而变大——这不是 bug，是编码切换阈值和内存对齐导致的。
- ziplist 编码的
HASH在字段数 ≤hash-max-ziplist-entries（默认 512）且单个 value ≤hash-max-ziplist-value（默认 64）时才启用；超限立刻转 dict，内存跳变明显 - jemalloc 分配粒度为 8/16/32/64 字节倍数，一个 65 字节的字符串实际占 80 字节，
MEMORY USAGE返回的就是这 80，而非 65 - 对带过期时间的 key，
MEMORY USAGE包含redisObject中的lru字段（8 字节）+ 过期字典中的 dictEntry（通常额外 32–48 字节）
真正要监控大 key，得组合使用三个命令
单靠 MEMORY USAGE 容易漏掉“伪大 key”：比如 key 本身很小，但所属数据库的 db.0 开销异常高（说明过期键堆积、dict 扩容未收缩、或大量空闲 slot 未回收）。
- 先跑
INFO memory看used_memory_overhead和used_memory_dataset比例：若 overhead 占比 > 60%，说明管理开销失控，不是某个 key 的问题，而是整体结构失衡 - 再用
MEMORY USAGE定向验证可疑 key，配合TYPE和DEBUG OBJECT（仅开发环境）看编码细节 - 最后用
MEMORY STATS查overhead.total、overhead.db、overhead.aof等子项，定位膨胀源头是 db 字典、客户端缓冲还是 AOF rewrite
最常被忽略的一点：Redis 7 的 MEMORY USAGE 对 STREAM 类型返回的是整个 radix tree + consumer groups 的总开销，哪怕只消费了一条消息，只要 group 存在，就计入——这会让 stream 看似“突然变大”，其实只是 group 元数据没清理干净。
