redis内存飙升多因bigkey，应优先在从节点用redis-cli --bigkeys扫描，避免主节点阻塞；它仅返回每类最大key且不反映真实内存，需结合memory usage和访问频次进一步分析。
Redis内存使用率突然飙升，十有八九是某个或多个 bigkey 在作祟——不是Key名长，而是它存的Value太大或元素太多。直接上 redis-cli --bigkeys 扫描是最快速的定位手段，但别急着在主节点跑，否则会卡住整个服务。
为什么 --bigkeys 不能在主节点随便执行
这个命令本质是遍历全库 + 对每个 key 做 TYPE + 类型特定大小估算（STRLEN、SCARD、HLEN 等），全程阻塞 Redis 单线程。实测一个 500 万 key 的实例，扫描可能持续几十秒，期间所有请求排队超时。
- 必须优先选从节点执行；没有从节点？只能压低业务流量后，在低峰期执行
- 加
-i 0.01参数让每次 scan 后休眠 10ms，能显著降低对主线程影响（但总耗时变长） - 它只返回「每种类型中最大的那个 key」，比如
hash类型只报出元素最多的那个，不会列出前 10 大 - 对集合类（
hash/zset）只统计元素个数，不反映实际内存占用——1 万个空字符串和 1 万个 10KB 的字符串，--bigkeys都显示为「10000」，但后者真实内存压力大得多
--bigkeys 输出结果怎么看
输出类似这样：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-------- summary -------\nSampled 100000 keys in the selected DB\nThere are 24746 strings greater than 10 kB\nBiggest string found 'user:profile:10086' has 123456 bytes\nBiggest hash found 'order:20260405' has 8921 fields
重点关注三类信息：
-
Biggest string found：值字节数超过默认阈值（通常 10KB）的stringkey，注意看具体字节数是否接近 1MB/10MB 级别 -
Biggest hash found：字段数超过 5000 的hash，但更要结合业务判断——比如order:20260405存的是单日订单快照，字段多合理；但如果是个用户配置user:conf:123有 8000 字段，大概率是数据写错或没清理 - 末尾的统计行（如
24746 strings greater than 10 kB）说明问题规模——如果上千个 string 都超 10KB，说明不是偶发，而是设计层面的问题
扫出来 bigkey 后，下一步做什么
找到 key 只是开始，关键是要确认它是否真在拖垮内存和性能：
- 用
MEMORY USAGE <key></key>查真实内存占用（Redis 4.0+），比--bigkeys的估算更准，尤其对hash/zset - 查访问频次：
SLOWLOG GET 10看有没有HGETALL、LRANGE这类 O(n) 命令频繁命中该 key；用INFO commandstats看cmdstat_hgetall耗时是否异常高 - 检查过期策略：如果 bigkey 设了
EXPIRE，但 Redis 版本 lazyfree-lazy-expire yes，过期瞬间就会阻塞主线程——这种“安静的炸弹”最难排查 - 不要直接
DEL！改用UNLINK（Redis 4.0+）异步删除，或对hash用HSCAN+HDEL分批删，避免主线程卡死
真正麻烦的 bigkey 往往藏在冷数据里：没人访问、不报慢日志、但占着几 MB 内存不动。这类 key 不会出现在 --bigkeys 的“最大”列表里，却会悄悄拉高内存水位。得靠定期跑 SCAN + MEMORY USAGE 全量采样，才能揪出来。
