Redis 大 key 分析：三条排查路径怎么选

# 1. 为什么大 key 是 Redis 的头号隐患

Redis 是单线程处理命令的，一次 DEL/EXPIRE/GET 大 key 如果耗时几十毫秒，就会阻塞这段时间内的所有其他请求——这跟数据总量无关，跟单个 key 的大小直接相关。一个几十万 field 的 Hash 或几十万元素的 List，光是遍历它就可能拖垮整个实例的响应时间。所以大 key 排查不是"锦上添花"的优化，而是稳定性刚需。

版本说明

--bigkeys 与 MEMORY USAGE 自 Redis 4.0 起可用，RDB 离线分析工具与 Redis 版本无关。

排查大 key 常见三条路径，各有取舍，按场景选：

# 2. 路径一：`redis-cli --bigkeys`（最快，在线扫描）

redis-cli --bigkeys

原理：用 SCAN 渐进式遍历所有 key，按类型（string/list/hash/set/zset）分别统计并输出每种类型里最大的那个。

预期输出：

-------- summary -------

Sampled 15234 keys in the keyspace!
Total key length in bytes is 312450 (avg len 20.51)

Biggest string found 'session:abc123' has 10240 bytes
Biggest hash   found 'user:profile:9999' has 512 fields

1
2
3
4
5
6
7

坑：SCAN 遍历本身是渐进式的、不会长时间阻塞，但统计维度只是"元素个数"或"字节数"的粗略估算，无法精确知道 Hash 里具体哪个 field 占用最多，而且这是采样估算，样本量不够时可能漏掉真正的大 key。生产环境用它做快速摸底合适，但不能拿它的结果直接下结论"没有大 key"。

# 3. 路径二：`MEMORY USAGE` 精确测单个 key

摸底之后，对 --bigkeys 报出的可疑 key 做精确测量：

<PUBLIC_IP>:6379> MEMORY USAGE user:profile:9999
(integer) 52480

1
2

返回的是这个 key 实际占用的字节数（含 Redis 对象头开销），比 --bigkeys 的估算更准确。可以配合 SAMPLES 参数控制对集合类型（hash/set/zset/list）采样的元素数，SAMPLES 0 表示不采样、精确统计全部元素（大集合下会更慢）：

<PUBLIC_IP>:6379> MEMORY USAGE user:profile:9999 SAMPLES 0

坑：MEMORY USAGE 本身是同步执行的，对于超大集合类型（几十万个 field 的 Hash）加 SAMPLES 0 精确统计会阻塞较长时间，线上环境慎用，建议先用默认采样值摸个大概再决定要不要精确统计。

# 4. 路径三：RDB 离线分析（不影响线上，看全局分布）

如果需要摸清整个实例甚至整个集群的大 key 全貌（而不是逐个 key 查），在线命令效率太低，更好的做法是导出 RDB 文件后离线分析，完全不占用线上实例的 CPU：

# 1. 各节点分别做一次 BGSAVE（fork 子进程落盘，主线程不阻塞）
redis-cli -h <node-ip> BGSAVE

# 2. 用 nc/scp 把各节点生成的 .rdb 文件收集到一台分析机器
nc -l 9000 > node1.rdb            # 接收端
cat dump.rdb | nc <analysis-host> 9000   # 发送端（示例）

# 3. 用 rdr 工具起一个 web 界面浏览 RDB 内容分布
wget https://github.com/xueqiu/rdr/releases/download/v0.0.1/rdr-linux
./rdr-linux show -p 8090 /opt/redisfile/*.rdb &

1
2
3
4
5
6
7
8
9
10

启动后通过浏览器访问 http://<analysis-host>:8090，可以按类型、按 key 前缀查看内存占用分布，比逐个 MEMORY USAGE 直观得多，适合定期（比如每周）巡检大 key 趋势。

工具地址：xueqiu/rdr (opens new window)

坑：BGSAVE 会 fork 一个子进程复制内存页表（写时复制），如果实例内存本身已经很紧张，fork 瞬间可能因为申请不到额外内存而失败，或者引发短暂的延迟毛刺——内存使用率高的实例上执行 BGSAVE 前最好先确认可用内存有冗余。

# 5. 三条路径怎么选

路径	适用场景	是否影响线上
`--bigkeys`	日常快速摸底，找可疑 key	轻微（SCAN 渐进式，可控）
`MEMORY USAGE`	对可疑 key 做精确确认	中等（大集合 + `SAMPLES 0` 会阻塞）
RDB 离线分析	全局巡检、集群级别、不想碰线上实例	仅 `BGSAVE` 瞬间 fork 开销

# 6. 可复用要点

Redis 大 key 问题的根因是"单线程 + 操作耗时和 key 大小成正比"，与数据总量无关。
--bigkeys 快但是估算值，别拿它当精确结论；MEMORY USAGE 精确但对超大集合有阻塞风险。
需要全局巡检或不想影响线上实例时，走 RDB 离线分析这条路径最安全。

#性能优化 #Redis

上次更新: 9/5/2026

← Redis 集群部署 Redis手动进行主从切换→