redis-cli --bigkeys 是最快定位各类最大 key 的轻量安全方式，5秒内采样输出每种类型中最大的一个，String超1KB、集合超1000元素即标记，但阈值不可调，仅适合快速摸底。
用 redis-cli --bigkeys 最快定位每种类型的“最大头目”
这是最轻量、最安全的线上探查方式，5秒内就能告诉你当前 Redis 里 String 最大的是哪个、Hash 字段最多的是谁——它不扫全量数据，而是采样扫描，基本不影响服务。
实操建议：
直接执行 redis-cli -h 127.0.0.1 -p 6379 --bigkeys；如果想降低扫描节奏（比如怕影响从库），加 -i 0.1 表示每次采样后休眠 0.1 秒；
注意它只显示每种类型（String/Hash/List/Set/ZSet）中“当前采样里最大的一个”，不会列出所有超限 key；
它的大小阈值是内置的：String 超 1KB、集合类元素超 1000 个就会被标记，但这个标准不能调，所以它适合快速摸底，不适合精准治理。
常见错误现象：
在主节点高峰期直接跑，其实风险不大，但如果你同时开了 --hotkeys 或连着跑多个分析命令，就可能叠加压力；
误以为输出里没看到大 key 就代表没有——其实它可能根本没采样到那个 key，或者该 key 属于低频但体积巨大的冷数据。
用 redis-rdb-tools 分析 RDB 文件，拿到全量内存排名
当你要精确知道“哪个 key 占了 82MB”“哪个 Hash 实际存了 27 万个字段”，就必须走这条路径。它不连 Redis 实例，只读取 dump.rdb 文件，零干扰、结果准，但需要你有服务器权限和一点操作耐心。
实操建议：
先用 redis-cli bgsave 触发后台快照（千万别用 save，会阻塞）；
找到 RDB 文件位置（看 redis.conf 里的 dir 和 dbfilename 配置，默认是 /var/lib/redis/dump.rdb）；
装工具：pip install redis-rdb-tools；
运行分析：rdb -c memory dump.rdb --bytes 1000000（表示只输出内存 ≥1MB 的 key）；
输出是 CSV 格式，含 key 名、类型、内存占用（bytes）、元素数量，可直接导入 Excel 排序。
容易踩的坑：
RDB 是某个时间点的快照，如果业务写入频繁，刚导出的文件可能已滞后几分钟；
某些 key 可能用了 LRU/LFU 淘汰策略，实际常驻内存比 RDB 显示的小，但治理时仍应以 RDB 结果为基准——因为淘汰不等于不存在风险。
写 SCAN + MEMORY USAGE 脚本做实时细粒度扫描
当你需要确认某个疑似大 key 的实时内存占用，或想按自定义阈值（比如“所有 >512KB 的 String”）批量捞出来，就得自己写脚本调用 SCAN 和 MEMORY USAGE。它灵活，但慢、有开销，必须控制节奏。
实操建议：
一定用 SCAN，绝对禁用 KEYS *（会阻塞 Redis 数分钟）；
每次 SCAN 后对返回的 key 批量调 MEMORY USAGE，别单个查（网络往返太伤）；
加休眠：Python 里用 time.sleep(0.01)，避免连续压测；
示例逻辑片段：for key in scan_iter(match="user:*", count=100): usage = redis_client.execute_command("MEMORY", "USAGE", key)；
设好阈值过滤，比如只记录 usage > 524288（即 512KB）的结果。
性能影响明显：MEMORY USAGE 对大 key 本身就要遍历结构，比如一个含 10 万成员的 ZSet，查一次可能耗时几十毫秒；
整库扫一遍可能要几十分钟，务必选在凌晨或业务低峰期，且建议限制 scan 的 count 参数别超过 500。
别忽略热 Key 和 BigKey 的耦合风险
很多故障不是单纯因为 key 大，而是“又大又热”。比如一个 30MB 的 Hash 被每秒 HGETALL 200 次，带宽瞬间打满，实例流控，其他请求全卡住。这种组合问题，--bigkeys 看不到热度，--hotkeys 又可能漏掉大体积——必须交叉验证。
实操建议：
先跑 redis-cli --bigkeys 拿出 top 大 key 列表；
再拿这些 key 去查慢日志（SLOWLOG GET 10）或监控系统，看它们是否高频出现在慢命令里；
更进一步：用 redis-cli --hotkeys -i 0.5 在从库低峰期跑一次，把结果和 bigkey 列表做交集；
重点关注类型是 hash 或 zset、且访问命令含 HGETALL/ZRANGE 0 -1 的 key——这类最危险。
最容易被忽略的一点：
BigKey 删除要用 UNLINK 而不是 DEL，但 UNLINK 对热 Key 效果有限——如果它正被大量客户端读，UNLINK 后的惰性删除仍可能触发瞬时 CPU 冲高。真正稳妥的做法，是先降热度（比如加本地缓存层拦截读），再拆分或迁移，最后清理。
