redis-cli --bigkeys 是低干扰初筛大 key 的唯一安全起点，需加 -i 0.1 参数并优先在从库执行；其输出仅为候选信号，须用 MEMORY USAGE 精确验证；RDB 分析可发现分散型大 key，但 size_in_bytes 非运行内存；过期积压与内存碎片是更隐蔽的静默消耗者。
用 redis-cli --bigkeys 做低干扰初筛
直接扫全量 key 会阻塞主线程，尤其在千万级 key 的实例上，redis-cli --bigkeys 是唯一能兼顾覆盖率和安全性的起点。它不查内存，但按类型（String/Hash/List/Set/ZSet）各返回一个“最大代表”——比如 Biggest hash found 'user:profile:123' has 48291 fields，这就是强信号。
必须加 -i 0.1 参数：每扫描 100 个 key 暂停 0.1 秒，把对延迟的影响压到毫秒级。别在高峰期主库跑，优先选只读从库（需临时设 slave-read-only no）或业务低峰期。
注意：--bigkeys 输出的 “has 48291 fields” 是元素数，不是字节数；String 类型才显示字节数。它只是筛出候选，不能当结论。
对候选 key 用 MEMORY USAGE 精确验证
MEMORY USAGE 返回的是真实内存占用（单位字节），包含键名、值、编码头、指针等全部开销。执行 MEMORY USAGE user:profile:123，若返回 8367254（约 8.4MB），就坐实了它是大 key。
关键限制：
- 该命令是阻塞式，单次调用没问题，但批量扫几百个候选 key 会拖慢服务
- 对 Hash/List/ZSet 等复合结构，结果是抽样估算（默认 SAMPLES=5），想更准可加
SAMPLES 100，但耗时明显上升 - 别在主库上循环调用 —— 优先走从库，或只查你从
--bigkeys或日志里人工圈出的 Top 10 候选
离线分析 RDB 文件避开运行时干扰
当 --bigkeys 找不到明显目标，或怀疑有“分散型大 key”（比如 log:20261019:* 一类命名规律强、单个不大但总量惊人），就得脱离线上实例，分析 RDB 快照。
步骤很明确：
- 确认 Redis 已生成最新 RDB（检查
save配置或手动BGSAVE） - 用新版
rdbtools或redis-rdb-cli（支持 RDB v12 格式）导出：rdb -c memory dump.rdb > memory.csv - CSV 含字段
db、type、key、size_in_bytes、encoding—— 注意：这个size_in_bytes是 RDB 序列化体积，不是运行时内存，仅作初筛 - 导入 Excel 或 ClickHouse，按
size_in_bytes降序，取 Top 100，再挑出其中符合命名特征的 key，回线上逐个MEMORY USAGE验证
别信 RDB 中的 size 字段对复合结构的参考价值：ZSet 的 size_in_bytes 只是成员数，完全不反映 value 长度；一个含 1000 个长字符串的 Hash，RDB size 可能只有几 KB，但实际内存轻松破 MB。
别漏掉“伪大 key”：过期积压与内存碎片
如果 used_memory 高但查不出大 key，立刻看 INFO memory 中两个指标：
-
expired_keys很大而evicted_keys几乎为 0 → 过期 key 没被及时清理，仍占内存（Redis 惰性删除 + 定期抽样，积压后就是隐形水位） -
mem_fragmentation_ratio > 1.5→ 内存碎片严重，used_memory没涨但used_memory_rss疯涨，此时优化方向是重启或启用activedefrag yes
真正难缠的从来不是显性大 key，而是这些不报错、不告警、只默默吃内存的“静默消耗者”。它们不会出现在 --bigkeys 输出里，也不会被 MEMORY USAGE 捕获，只能靠 INFO memory 的全局指标交叉印证。
