Redis MEMORY USAGE 为什么和实际占用不一样：采样深度、嵌套对象与容量估算

排查 Redis 内存时，最容易把两个数字混在一起：MEMORY USAGE key 看的是一个键及其值在内存中的估算，INFO memory 里的 used_memory 看的是实例级用量。前者变大，不代表实例总量会按同样比例增长；嵌套数据类型还会受到采样数量影响。

先用 MEMORY USAGE 定位可疑键，再用 SAMPLES 0 复核嵌套成员，最后把结果和 INFO memory 分开解释，才不会把采样估算当成精确账单。

告警现场：单个大键并不等于实例总量

假设慢查询和内存告警同时出现，先抽到一个很大的 Hash 键。执行下面的命令：

MEMORY USAGE user:profile:10086
INFO memory

第一行返回字节数，第二段返回实例维度的统计。两者的统计对象不同：前者包括该键、值和 Redis 为它们维护的管理开销，后者还包含其他键、复制缓冲区、客户端缓冲区以及分配器相关信息。这里别急着用一个键的数字去解释整台实例。

嵌套对象为什么会受 SAMPLES 影响

String 的值没有嵌套成员，采样参数对它没有实际意义；Hash、List、Set、Sorted Set 等聚合类型则可能包含大量成员。Redis 文档给出的默认值是 SAMPLES 5：命令从嵌套值中抽取样本，按样本平均大小估算总量；SAMPLES 0 才会把全部嵌套值纳入计算。

可以这样做一次可复现的对照：

MEMORY USAGE user:profile:10086 SAMPLES 5
MEMORY USAGE user:profile:10086 SAMPLES 0

如果两次结果差距明显，说明这个键的成员大小并不均匀，默认五个样本不能代表全部成员。若差距很小，也只能说明这个键的样本比较稳定，不代表其他键同样稳定。

采样数量不是“越大越安全”

SAMPLES 0 的代价是遍历全部嵌套值。对一个成员数很大的 Hash 或 Sorted Set，在线上批量执行会给主线程增加额外工作。更稳妥的顺序是先从抽样结果筛出少量候选键，再对单个键做一次全量复核，把命令输出保存到排查记录中。

把单键估算和全局内存拆开看

当一个键的报告已经足够大，下一步不是立刻删除，而是确认它在实例总量中的比例：

MEMORY USAGE user:profile:10086 SAMPLES 0
INFO memory

重点记录 used_memory、used_memory_rss、mem_fragmentation_ratio 等字段，再结合键空间扫描或业务维度统计。下面这张图把两个查询的关系固定下来：MEMORY USAGE 负责单键证据，INFO memory 负责实例背景，不能把后者当成前者的汇总接口。

还有一个常被忽略的边界：键不存在时，RESP2 返回 nil，RESP3 返回 null。脚本或监控采集器应把它当作“键已消失或采集时机不一致”处理，而不是把空值转成 0 后继续计算。

生产排查的最小工作流

1. 从业务前缀、慢命令或抽样扫描中锁定少量候选键，不在高峰期对全库逐键执行 SAMPLES 0。
2. 先执行默认的 MEMORY USAGE key，再对最可疑的聚合键执行 SAMPLES 0 做复核。
3. 同步采集 INFO memory，区分键值增长、分配器碎片、复制和客户端缓冲区。
4. 确认业务是否仍需要这些成员后，再选择拆分键、缩短 TTL、调整数据结构或分批清理，并观察复核结果。

这套顺序的价值在于先缩小范围、再增加测量成本。仅凭一个很大的单键数值就改 maxmemory 或批量删除，往往会把容量问题变成业务抖动。

常见问题

MEMORY USAGE 返回 nil 是 Redis 出错了吗？

通常不是。目标键不存在时，Redis 按协议返回 nil 或 null。检查键是否过期、是否查错数据库，以及采集前后是否发生了删除。

为什么同一个 Hash 每次默认结果可能不同？

默认聚合类型只采样一小部分嵌套值；成员大小分布不均时，抽到的样本不同，估算也会变化。需要核对时使用 SAMPLES 0，但要控制频率。

单键总和能替代 INFO memory 吗？

不能。单键报告只回答键和值的占用，实例级统计还包含其他对象、管理开销、客户端和复制相关内存，以及分配器表现。

复核结论

MEMORY USAGE 是定位单键的证据工具，不是 Redis 全局内存账本。对嵌套对象先接受默认采样带来的估算属性，锁定候选后再用 SAMPLES 0 复核；同时保留 INFO memory 的实例背景，才能把“某个键很大”和“实例为什么逼近上限”分成两个可验证的问题。