是的，redis-cli --bigkeys 默认全量扫描当前数据库所有key，逐个执行TYPE及对应结构大小命令，非采样；不支持pattern过滤，无法跨库，会统计已过期未删除key，对list/hash/zset仅粗略估算内存而非精确测量。
redis-cli --bigkeys 会扫描整个数据库吗
是的，redis-cli --bigkeys 默认会遍历当前选中数据库（SELECT 指定的 db）里的**所有 key**，逐个执行 TYPE 和对应结构的大小探测命令（如 STRLEN、LLEN、SCARD、HLEN、ZCARD）。它不是采样，而是全量扫描——这意味着在大库上运行可能阻塞主线程、拖慢业务，尤其当 key 数量超百万时。
常见错误现象：执行后 Redis 响应明显变慢，INFO stats 中 instantaneous_ops_per_second 骤降，客户端出现超时；后台日志里没有报错，但监控看到 used_memory_peak_human 突增（因扫描过程本身也占临时内存）。
- 它不支持指定 pattern 过滤（比如只查
user:*），必须配合--scan+SCAN游标方式间接实现，但原生命令不提供该能力 - 扫描期间无法切换数据库（即不能一边扫 db0 一边跳去 db1），每次只能针对一个 db 执行
- 对已过期但尚未被惰性/定期删除的 key，仍会纳入统计——这些 key 实际已无效，但
--bigkeys看不到 TTL，会误判为“活跃大 key”
为什么 scan 出来的最大 list 长度和实际 LLEN 不一致
因为 redis-cli --bigkeys 对 list 类型用的是 LLEN，但它的采样逻辑有隐藏限制：默认只检查前 100 个元素的平均长度，再乘以总长度估算“内存占用”，而非真实序列化体积。所以会出现「报告 list 有 50MB，但 LLEN 只有 1 万，每个元素才 5KB」这种矛盾。
根本原因是 Redis 的 list 底层可能是 ziplist 或 quicklist，而 --bigkeys 完全不感知编码细节，只粗略估算。它真正关心的是“这个 key 是否可能引发 OOM 或阻塞”，而不是精确字节数。
- 遇到疑似误报，直接用
LINDEX key 0和LINDEX key -1抽查首尾元素长度，再结合DEBUG OBJECT key（需开启notify-keyspace-events且非生产环境慎用）看编码和实际 malloc 大小 - 如果 list 元素极不均匀（比如第 9999 个元素是 10MB 图片 base64），
--bigkeys会漏掉——它只看前 100 个 - hash / zset 同理：用
HLEN/ZCARD代替真实内存测量，字段值长短差异大时，结果参考价值下降
如何安全地在生产环境跑 --bigkeys
别直接在高峰时段连主节点跑。最稳妥的方式是连接从节点（replica），并确保该从节点不承担读流量或已降权。即使如此，仍需控制扫描节奏，避免触发复制缓冲区溢出（repl-backlog-size 不足）。
- 加
-i 0.1参数：每查完一个 key 后 sleep 100ms，大幅降低 CPU 和内存毛刺（默认无延迟） - 用
timeout 300s redis-cli -h host -p port --bigkeys -i 0.1加超时兜底，防卡死 - 避开
save或bgsave正在进行的时间段——fork 子进程时内存 copy-on-write 会放大扫描开销 - 若 Redis 版本 client-output-buffer-limit replica 512mb 256mb 60），否则从节点可能断连
扫描结果里的 “Biggest string found” 是指什么
它指的是当前数据库中 STRLEN 值最大的 string 类型 key，单位是字节。注意：这不是“占用内存最多”的 string，而是“内容最长”的 string。Redis string 的内存开销 = 内容长度 + SDS 头部（通常 8~16 字节）+ 分配冗余（jemalloc 可能多分一倍），所以 --bigkeys 显示的 10MB，实际 redis-memory-analyzer 或 MEMORY USAGE 可能返回 12MB。
容易忽略的一点：--bigkeys 不会告诉你这个 string 是否被频繁访问。一个 8MB 的冷 key 和一个 2MB 的热 key，前者可能更该删，后者却更该优化访问模式。
如果发现多个 string 超过 1MB，优先检查是否误存了图片、序列化 blob 或日志文本——Redis 不适合存这类数据，应转存到对象存储，key 只留 URL 或 ID。
