redis-cli --bigkeys仅按元素数或字符串长度统计，不反映真实内存占用，需配合MEMORY USAGE、OBJECT ENCODING等命令人工验证；它每种类型只报Top 1，且扫描期间新增key会漏掉。
用 redis-cli --bigkeys 快速筛出可疑大Key，但别全信它
redis-cli --bigkeys 是最常用的起点，但它只基于 SCAN 采样统计，对 Hash/Set/ZSet 类型仅报告元素个数，不反映真实内存占用。比如一个含 8000 个 field 的 Hash，每个 value 是 2KB 的 JSON，总内存可能超 15MB，但 --bigkeys 只会标为 “hash with 8000 fields”，不会告诉你它正在拖垮复制流。
实操建议：
- 加
-i 0.1降低扫描干扰：redis-cli -h master-host -p 6379 --bigkeys -i 0.1 - 对扫出的候选 key，必须补查真实内存：
redis-cli MEMORY USAGE keyname - 同时确认类型和规模：
redis-cli TYPE keyname+redis-cli HLEN keyname或ZCARD keyname - 绝对禁用
KEYS *，它会阻塞主线程，尤其在 Redis 5.0 这类无多线程 IO 的版本里，一次扫描就可能引发秒级卡顿
查 INFO replication 和网络指标，确认大Key是否已造成同步断连
Redis 5.0 主从复制依赖 repl-backlog 和 client output buffer，大Key极易打穿后者。若从节点反复断连、重同步，大概率是 client-output-buffer-limit slave 被击穿（默认 256MB/64MB/60s）。
关键检查项：
- 运行
redis-cli INFO replication，看slave_repl_offset是否长期停滞，或与master_repl_offset差值持续扩大 - 查主节点网络输出：
redis-cli --stat | grep output，观察instantaneous_output_kbps是否在某次操作后突增至数百 MB/s（典型大Key序列化传输特征） - 检查从节点日志是否有
Timeout waiting for bulk read或Connection lost—— 这不是网络问题，是主节点发不出完整大Key导致的超时 - 确认主节点配置：
redis-cli CONFIG GET "client-output-buffer-limit slave"，若仍是默认值，一个 300MB 的 ZSet 就足够触发断连
用 MEMORY USAGE + OBJECT ENCODING 判断大Key的真实压力来源
同一个逻辑结构，编码方式不同，性能表现天差地别。比如一个本该用 ziplist 编码的 Hash，因单个 value 超过 hash-max-ziplist-value（Redis 5.0 默认 64），被转成 hashtable，内存占用翻倍，遍历耗时也指数上升——这种“隐性大Key”更危险。
操作步骤：
- 对疑似 key 执行：
redis-cli MEMORY USAGE keyname获取实际字节数 - 执行：
redis-cli OBJECT ENCODING keyname看当前底层编码（ziplist/hashtable/quicklist等） - 结合
redis-cli CONFIG GET "hash-max-ziplist-*"等参数，反推为何编码升级 —— 往往是某个 field value 意外变大，而非整体膨胀 - 特别注意
quicklist编码的 List：即使元素不多，若每个 node 都存了大 value，MEMORY USAGE会远高于LLEN提示的规模
在主节点用 SCAN + HSCAN 渐进式验证，避免误判热Key为大Key
很多团队把高频访问的 Key 当作大Key处理，结果白忙一场。热Key（如 config:global）可能每秒被读几千次，但只是个几 KB 的 String；而真正的大Key（如 rank:202610:week）可能一天只写一次，却占 400MB 内存。两者危害机制完全不同。
验证方法：
- 用
redis-cli --scan --pattern "rank:*"快速定位业务前缀下的候选 key - 对每个候选执行
HSCAN keyname 0 COUNT 100，观察游标是否能快速返回、还是卡在某次调用（卡住 = 大Key内部遍历慢） - 配合
SLOWLOG GET 5查最近慢查询，看是否集中出现在某个 key 上 —— Redis 5.0 的慢日志能记录命令耗时，是判断是否“真卡”的直接证据 - 不要在从节点执行任何扫描类命令，所有诊断必须在主节点完成，否则看到的是过期数据或只读视图，无法反映真实复制压力源
大Key排查最易忽略的一点：它往往藏在“不该有数据的地方”。比如一个本该按天清理的 log:buffer:20261019，因 TTL 设置错误或过期键未被及时回收，持续累积三个月，最终变成 2GB 的 List。这类 Key 不在常规监控维度里，也不会出现在 --bigkeys 的高频采样中，只能靠定期 SCAN + MEMORY USAGE 组合巡检才能揪出来。
