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 替代
