MEMORY OVERHEAD 是什么
MEMORY OVERHEAD 按分配尺寸把键空间里的对象分桶统计：每个尺寸段有多少键、合计多少字节、平均每键多少字节。它回答的是一个具体问题——内存是被数据本身占走的，还是被大量小对象的结构开销吃掉的。
基本信息
| 命令 | MEMORY OVERHEAD |
|---|---|
| 起始版本 | Redis 4.0 |
| 输出 | 按尺寸分桶的计数与字节数 |
| 用途 | 评估结构开销占比，指导编码与键设计 |
| 副作用 | 只读统计 |
典型使用场景
- 大量小键的场景里判断瓶颈是「键太多」还是「值太大」
- 评估把多个小字符串合并为 Hash 或改用整数 ID 的收益空间
- 大 key 排查时，用平均值与总量确定优先处理对象
- 容量规划时估算每键的真实成本，而不只看平均 value 大小
- 压测后核对内存增长是否符合预期
交叉验证用法
交叉验证用法
redis-cli MEMORY OVERHEAD # 分桶视图
redis-cli DBSIZE # 键总数，与分桶计数互相印证
redis-cli INFO memory | grep used_memory_human # 总占用，作为占比分母
redis-cli MEMORY USAGE user:1001 # 抽样看单键的实际字节数
redis-cli OBJECT ENCODING user:1001 # 编码不同，开销差别很大
redis-cli MEMORY DOCTOR输出逐列读法
| 字段 | 含义 | 怎么读 |
|---|---|---|
| Bytes per key | 该尺寸档每键平均字节数 | 明显贴近最小档，说明键粒度太碎 |
| Count | 该尺寸档的键数量 | 集中在最小档时，结构开销占比通常偏高 |
| Total bytes | 该尺寸档合计占用 | 用总量占比决定优化顺序 |
平均值受编码影响很大：同样是 Hash，紧凑编码与哈希表编码的单键开销可以相差数倍；调整编码阈值前先确认当前元素数量与配置。
拿到数据后的三步判断
- 先比键总数与总字节，确定平均每键成本是否合理
- 再看分桶分布，判断是否存在大量小于结构开销的小键
- 抽样 MEMORY USAGE 与 OBJECT ENCODING，核对真实开销
- 把结论落成动作：合并键、改编码、缩短键名或拆分实例
键名本身也占空间：长键名与长前缀在百万级键量下会变成可观开销，估算每键成本时不要漏掉这部分。