Redis MEMORY USAGE 与实际对象占用的核对

排查 Redis 内存时，最容易混淆的是“一个 key 占多少”和“整个实例用了多少”。MEMORY USAGE key 返回的是指定 key、它的值以及相关管理开销在 RAM 中的字节估算；它不是进程 RSS，也不能单独解释实例为什么接近 maxmemory。

官方文档：https://redis.io/docs/latest/

MEMORY USAGE 先回答的是哪一个问题

把它当成“这个 key 在 Redis 数据结构里大约占多少字节”的工具更准确。返回值包含键、值、数据结构和管理开销，因此一个看起来很短的字符串也会有固定的额外占用。键不存在时，返回的是空值而不是零。

# 查询一个具体 key 的内存估算，返回单位是字节
redis-cli MEMORY USAGE user:1001

# 查询结果不存在时只表示该 key 当前不存在
redis-cli MEMORY USAGE user:not-found

所以核对时先记下 key 的数据类型和采样方式，再记录返回字节数。不要拿业务字符串长度直接和这个结果做一一对应。

集合型对象要看 SAMPLES 参数

字符串、列表、集合、有序集合和哈希的内部成员数量可能很大。对嵌套值，MEMORY USAGE key 默认抽样 5 个成员来估算总量；这适合快速定位，但不等于逐成员精确求和。

# 使用默认抽样，适合先定位异常大的集合
redis-cli MEMORY USAGE cart:1001

# 对嵌套成员执行全量采样，适合对单个对象做更细核对
redis-cli MEMORY USAGE cart:1001 SAMPLES 0

SAMPLES 0 会遍历全部嵌套值，数据量大时应把它限定在单个排查对象上，不要把它当作批量巡检命令。默认抽样值与全量值差异较大时，通常说明成员大小分布不均，需要继续按数据类型和成员结构拆分判断。

为什么单键结果不能直接代表实例内存

实例级内存还包含客户端缓冲区、复制积压、AOF 缓冲、数据库字典和脚本缓存等部分。可以用 INFO memory 先看当前分配与 RSS，再用 MEMORY STATS 看更细的组成；这些统计对象和单个 key 不在同一层。

# 查看实例级内存字段，重点对照 used_memory 与 used_memory_rss
redis-cli INFO memory | egrep 'used_memory:|used_memory_peak:|used_memory_rss:'

# 查看客户端、复制积压等实例级组成
redis-cli MEMORY STATS

Redis 官方内存优化说明还提醒，删除数据后分配器未必立即把页面归还给操作系统。因此出现“业务数据减少了，但 RSS 仍然偏高”时，先不要把差值全部归因到某个 key；应同时看当前分配、历史峰值和分配器复用情况。

把一次核对结果写成可复查记录

建议按“键名—类型—命令—采样方式—字节数—实例级对照”记录，而不是只保存一个数字。对快速排查，可先用默认抽样找出异常对象，再对少数对象使用 SAMPLES 0。如果目标是解释机器内存压力，则必须补充 used_memory_rss、客户端和复制相关统计。

• 单键变大：优先检查 key 名长度、值的编码方式和集合成员分布。
• used_memory 高：确认当前数据与实例级开销是否共同增长。
• RSS 高但当前分配下降：结合峰值和分配器复用判断，不把 RSS 当作 key 大小总和。

常见问题

MEMORY USAGE 返回的字节数等于 value 长度吗？

不等于。它还包含 key、内部数据结构和管理开销，小对象的固定开销尤其明显。

SAMPLES 0 是否应该用于所有 key？

不建议。它适合少量重点对象的细核对；大集合全量遍历会增加命令本身的工作量。

删除大量 key 后 RSS 没降，说明删除失败了吗？

不一定。Redis 可能已经减少当前分配，但底层分配器保留了可复用页面，应该同时比较 used_memory 和 RSS。