memory usage 返回键名、值数据、redisobject元数据、过期字典dictentry、底层容器开销（如hash桶数组）、内存对齐填充等全部实际分配内存，但不包含aof/rdb缓冲、不体现对象共享、不区分是否已过期。

MEMORY USAGE 是 Redis 7 中最贴近真实内存开销的单 key 分析命令，但它返回的不是“你存进去的数据大小”，而是 Redis 运行时为这个 key 实际分配的全部内存——包括值、键名、编码结构体、哈希表扩容冗余、过期字段、指针、内存对齐填充等。想靠它精准定位大 Key 的内存瓶颈，得理解它“算什么”和“不包含什么”。

MEMORY USAGE 返回的是哪些开销？

它反映的是 jemalloc（或当前内存分配器）实际向操作系统申请的字节数，具体含：

• 键名字符串本身占用 + 空终止符
• 值数据（如字符串内容、hash 字段名/值对）原始字节
• redisObject 元数据：类型、编码、LRU 时间戳（8 字节）、引用计数等
• 若带过期时间：额外占用 redisDb 过期字典中的 dictEntry（通常 32–48 字节）
• 集合类结构的底层容器开销：比如 hash 从 ziplist 切换为 dict 后，桶数组（如 262144 个 bucket）、entry 结构体、指针等全计入
• 内存对齐填充：jemalloc 按 8/16/32/64 字节粒度分配，一个 65 字节字符串实际占 80 字节，MEMORY USAGE 就返回 80

为什么它比 --bigkeys 更准，又不能直接信？

--bigkeys 只做采样估算：对 hash 只查几个 field 算平均，忽略 dict 扩容、编码切换、元数据；而 MEMORY USAGE 是运行时真实分配量。但这也带来偏差：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 已过期但尚未被惰性/定期删除的 key，仍全额计入
• 不体现对象共享（refcount > 1 的字符串不会被重复计）
• 不包含 AOF 缓冲区、RDB 临时缓冲、复制积压缓冲等运行时临时开销
• 对压缩编码（如 ziplist hash）可能“反直觉”：字段略超阈值触发编码切换，内存占用会跳变式增长

执行前必须确认的三件事

避免误判或引发线上抖动：

• 确认 key 存在且类型明确——对不存在的 key，返回 0，容易当成“空 key”漏掉
• 避开业务高峰批量调用——一次查 100 个大 key 可能触发主线程阻塞，可用 SLOWLOG GET 查是否进慢日志
• 检查 client-output-buffer-limit 设置——若结果过大（如 50MB+），输出缓冲区溢出会导致连接被强制断开

怎么用才真正落地有效？

别只查单个 key，要结合场景形成闭环：

• 先用 redis-cli --bigkeys -i 0.1 快速筛出可疑 key（按元素数或字节数 Top N）
• 对筛选出的 key，逐个执行 MEMORY USAGE keyname，记录结果并比对预期
• 若发现明显偏高（如 10 万字段 hash 报 10MB+），再用 DEBUG OBJECT keyname 查编码、refcount、lru 等辅助信息
• 对高频更新的大 hash/list，考虑拆分（如按时间分片、按用户 ID 取模）或改用 stream + consumer group 替代