redis-cli --bigkeys 不能精准定位内存大 key，因其仅统计逻辑大小（如STRLEN、HLEN），与实际内存占用无关；真要识别内存大户，须用 MEMORY USAGE 配合 SCAN 或离线分析 RDB。
redis-cli --bigkeys 不能精准揪出大 Key，它只返回每种类型里“逻辑最大”的那个，和真实内存占用基本无关；真要定位内存大户，必须用 MEMORY USAGE 配合 SCAN 脚本或离线分析。
为什么 --bigkeys 显示的“最大”和内存占用对不上
它统计的是「逻辑大小」：对 String 用 STRLEN，对 Hash 用 HLEN，对 List 用 LLEN —— 全都不反映实际内存开销。一个 Hash 只有 10 个 field，但每个 value 是 1MB 的 Base64 图片，--bigkeys 会把它当小 key 漏掉；而一个含 10 万个空字符串的 List，LLEN 返回 100000，但真实内存可能超 5MB。
常见错误现象：INFO memory 显示 used_memory_dataset 很高，但 --bigkeys 输出全是“几十字节”“几百字段”，毫无异常感。
-
--bigkeys默认只查db0，业务 key 在db1或db15？必须加-n 1或-n 15 - 它不识别编码差异：ziplist 升级为 hashtable 后内存翻倍，但
HLEN值不变 - 输出里的 “Biggest string found … has 89885 bytes” 是
STRLEN结果，不是MEMORY USAGE
什么时候可以用 --bigkeys 快速筛出线索
它适合做第一轮粗筛，前提是知道它的能力边界：只在明显偏离均值时才有效。比如某 Hash 有 48291 个 field（远超平均 200），或某 String 的 STRLEN 达到 89KB，这种强信号值得记下来立刻验证。
- 加
-i 0.1参数降低影响：每扫描 100 个 key 暂停 0.1 秒，避免压垮主节点 - 优先在从库或低峰期运行，千万级 key 下可能跑几十分钟
- 输出末尾的 summary 里 “avg size” 比单条 biggest 更有价值：如果
565 strings平均 687 字节，但某一个标出 89KB，就是异常点
真正定位内存大户的实操路径
拿到疑似 key 名后，必须立刻执行 MEMORY USAGE 验证。Redis 4.0+ 都支持，返回单位是字节，足够判断是否越界。
- 对
user:profile:123执行MEMORY USAGE user:profile:123，返回8367254≈ 8.4MB → 确认是问题源 - 对集合类型，该命令是抽样估算，但误差在可接受范围；若返回几百 MB，不用再怀疑
- 若
--bigkeys没给出任何强信号，说明大 key 可能藏在命名规律性强、单个不大但总量惊人（如日志快照序列），此时必须切 RDB 文件分析 - 用
rdb -c memory dump.rdb > memory.csv导出后按size_in_bytes排序，避开运行时干扰
容易被忽略的“伪大 key”陷阱
有时 used_memory 高，但扫不出大 key，问题不在数据本身，而在生命周期管理。
- 检查
INFO memory中的expired_keys：如果数值很大（比如百万级），但evicted_keys几乎为 0，说明过期 key 积压未清理 - 看
mem_fragmentation_ratio：>1.5 就存在严重内存碎片，used_memory高但实际可用内存低 -
--bigkeys完全不感知这些，它们不会出现在 SCAN 结果里，却持续占着内存
真正难搞的从来不是那个一眼可见的 800MB ZSet，而是分散在几百个命名相似的 key 里、每个 2MB 但总和超 20GB 的日志 blob，或是积压了三天没被抽样清理的过期 key。这些，--bigkeys 根本看不到。
