redis-cli --bigkeys在集群中仅扫描单节点（默认首个master的db0），无法自动遍历所有分片；需手动逐个连接各master节点执行，并配合memory usage、cluster keyslot等命令精准定位与验证大key。
redis-cli --bigkeys 在集群中只能扫单节点，别指望它自动遍历所有分片
它根本不知道你在用 Redis Cluster，执行时默认连第一个节点（通常是 0 号分片），只分析那个节点的 DB 0。你看到 Biggest string found 'user:profile:1001'，不代表这个 key 就在该节点——它可能被哈希到别的分片上，而你压根没连过去。
常见错误现象：在集群入口（比如 proxy）上跑 redis-cli -c --bigkeys，结果报错或返回空；或者只在 master 节点扫完就以为全局摸清了，结果线上某个从节点内存飙升却没线索。
实操建议：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 先用
redis-cli -c -h {node} -p {port} cluster nodes拿到全部分片地址和角色 - 对每个 master 节点单独执行：
redis-cli -h {ip} -p {port} --bigkeys -i 0.01（加-i 0.01防止采样过猛） - 注意区分
MOVED重定向行为：带-c参数时，--bigkeys会失效，必须去掉-c手动连具体节点 - 如果用的是 Codis 或 Twemproxy 这类代理，
--bigkeys更无效——它们不透传该命令，得直连后端真实 Redis 实例
为什么集群里扫出的“最大 Key”常和内存监控对不上
因为 --bigkeys 统计的是“当前采样下每种类型最大的一个”，不是“内存占用 Top N”。比如某分片上有 3 个 Hash，大小分别是 8MB、7.9MB、7.8MB，它只报 8MB 那个；但如果你的监控显示该节点内存突增 25MB，那另外两个加起来才是关键。
更麻烦的是：集群中不同节点数据分布不均，--bigkeys 输出里 “Biggest hash found 'order:batch:202604' has 12000 elements” 看似不大，但如果这个 Hash 的每个 field 值都很大（比如存了 base64 图片），实际内存可能超 20MB——而 --bigkeys 对集合类只看元素个数，不查 MEMORY USAGE。
实操建议：
- 发现疑似大 key 后，立刻切到对应节点执行：
MEMORY USAGE order:batch:202604，看真实字节数 - 用
DEBUG OBJECT order:batch:202604查serializedlength和编码方式（如hashtablevsziplist），判断是否已触发内存膨胀 - 结合
INFO memory | grep used_memory_human对比节点间差异，内存明显偏高的节点优先深挖
集群环境下删大Key前必须确认三件事
在单机 Redis 上用 UNLINK 已经是常识，但在集群里，这事更敏感：删错节点、删错副本、删的时候主从不同步，都可能引发数据不一致或请求失败。
实操建议：
- 先确认 key 确实在目标节点：用
redis-cli -h {ip} -p {port} CLUSTER KEYSLOT order:batch:202604得到 slot，再用CLUSTER GETKEYSINSLOT {slot} 1验证 - 检查该 slot 的主从状态：
CLUSTER NODES中找对应 slot 的 master 和 slave，确保 slave 复制延迟 slave0 行的 offset 差值） - 删之前先
UNLINK主节点，等几秒再查EXISTS；确认成功后再连从节点执行一次UNLINK（避免主删了但从还挂着导致后续写入冲突） - 别在故障转移窗口期操作：比如刚发生 failover，
CLUSTER INFO显示cluster_state:fail或cluster_slots_pfail非零时，暂停一切大 key 操作
真正要定位“哪个节点被大Key拖垮”，得看指标+日志交叉验证
--bigkeys 是起点，不是终点。集群里一个节点 CPU 持续 90%、客户端大量 TIMEOUT、慢日志里频繁出现 HGETALL 或 LRANGE，这些信号比 --bigkeys 输出更早暴露问题。
容易踩的坑：只盯着 used_memory，忽略 mem_fragmentation_ratio。比如某节点 mem_fragmentation_ratio 达到 2.3，说明后台释放不掉碎片内存，即使你 UNLINK 了大 key，内存也不回落——这时候得在该节点上 CONFIG SET activedefrag yes，而不是继续找新大 key。
实操建议：
- 把每个节点的
INFO commandstats中cmdstat_hgetall:calls=和cmdstat_lrange:calls=调出来，排序看哪几个节点调用量异常高 - 检查
SLOWLOG GET 10，重点关注耗时 > 100ms 的命令，反查 key 名，再用CLUSTER KEYSLOT定位节点 - 观察
INFO replication的master_repl_offset和从节点 offset 差值，持续拉大说明主节点在忙于处理大 key 相关请求，无法及时同步
大 key 的危害从来不在“有多大”，而在“在哪、谁在读、删了会不会断服务”。--bigkeys 只给你一个名字，剩下的得靠指标、日志、节点状态三者对齐才能动手。
