Redis MEMORY USAGE 怎么定位单个键的内存膨胀：SAMPLES、集合成员与处置顺序

Redis 的内存告警先别急着改 maxmemory。INFO memory 能说明实例总量在上涨，却不能告诉你是哪一个键把空间吃掉了；把范围缩到具体键后，再用 MEMORY USAGE 核对字节数，通常比盲目清缓存更稳。

从 INFO memory 到具体键：先把告警范围缩小

假设实例的 used_memory 连续升高，慢查询和连接数却没有明显变化。第一步只做总量确认，不要直接扫描所有键：

redis-cli INFO memory | grep -E 'used_memory_human|maxmemory_human|mem_fragmentation_ratio'
redis-cli --scan --pattern 'user:*:feed' | head -20

INFO memory 的结果只能回答“实例现在有多大”。真正需要回答的是：某个业务键是否比同类键大很多，以及它的大小是否和成员数量相称。生产环境可以先从增长最快的业务前缀抽样，避免一次性把全库键名搬到客户端。

MEMORY USAGE 怎么读：字节数不是 value 的字符串长度

拿到候选键后，直接测量它在 Redis 内部占用的近似字节数：

redis-cli MEMORY USAGE user:42:feed
redis-cli TYPE user:42:feed
redis-cli TTL user:42:feed

返回值包含键对象、编码和 value 结构的开销，所以它通常会大于业务字符串的长度。TYPE 与 TTL 是两项不能省略的旁证：一个大 Hash 可能是用户动态聚合，也可能是没有分片的异常键；一个没有过期时间的临时缓存，则要优先回到写入代码查默认 TTL。

集合键的 SAMPLES 边界：估算前先知道成员规模

对 List、Set、Hash 和 Sorted Set，MEMORY USAGE 可以带 SAMPLES 参数。它不是“抽样读取业务数据”，而是告诉 Redis 在估算集合成员平均开销时采样多少个元素：

redis-cli MEMORY USAGE members SAMPLES 0
redis-cli MEMORY USAGE members SAMPLES 5
redis-cli SCARD members
redis-cli DBSIZE

SAMPLES 0 表示不抽样，适合需要完整测量的核验窗口，但对超大集合要留意额外工作量。设置较小的样本数时，返回值更适合快速巡检；如果集合成员大小差异很大，采样结果就可能偏离真实平均值。此时要把 SCARD members 和多次测量一起记录，而不是只看一次数字。

处置顺序：先分清异常大键和合理业务集合

测到大键后，最安全的动作是建立证据链。先保存键名、类型、字节数、成员量和 TTL；再对照同一业务下的几个正常键。如果只有一个键异常，优先查写入路径是否缺少截断或过期；如果同类键整体变大，可能是字段结构或缓存策略变化。

redis-cli MEMORY USAGE members SAMPLES 5
redis-cli TYPE members
redis-cli SCARD members
redis-cli PTTL members

不要在业务高峰直接对大集合做全量导出。可以先限制生产者写入、补上 TTL 或拆分键空间，再在低峰做小批量迁移；删除也要确认业务没有并发写回，否则刚清掉的空间可能立刻再次增长。

常见问题：MEMORY USAGE 排查时容易误判什么

MEMORY USAGE 为什么和字符串长度对不上？

它统计的是 Redis 对象及其内部编码的近似内存占用，不只是 value 的字节长度。比较时应保持键类型和数据形态一致。

SAMPLES 设置越大就一定越准确吗？

更大的样本通常能降低成员大小差异带来的估算偏差，但也会增加核验成本。集合成员分布均匀时，小样本巡检已经足够；差异很大时应提高样本并重复测量。

发现大键后能不能马上 DEL？

不建议。先核对业务归属、TTL、成员量和写入方，再选择限长、拆分、补 TTL 或低峰清理，并观察处置后的内存变化。

只看 INFO memory 能定位大键吗？

不能。它适合确认实例总量和碎片情况，具体键仍需要 MEMORY USAGE 与 TYPE、成员数量等信息组合判断。

把一次告警变成可复查的检查清单

一轮排查结束时，至少留下三组结果：实例总量、候选键明细、处置后的复测值。这样下次同一前缀再次上涨时，可以区分是旧键复发、写入量增加，还是集合成员结构发生了变化。Redis 的内存治理重点不是找到一个“最大键”就结束，而是让键的大小、生命周期和业务写入规则彼此对得上。