Redis BigKey指String值超10KB或集合类元素超5000个等内存过大key，会导致内存不均、阻塞操作和删除卡顿；定位推荐redis-cli --bigkeys（低峰期/从库执行）、MEMORY USAGE精确查内存、rdb-tools离线分析；删除须渐进式分批操作，禁用直接DEL大key。
Redis 出现内存暴涨、响应变慢或主从延迟加剧，大概率是 BigKey 在作祟。它不是 Key 名字长，而是 Value 占用内存过大——String 超过 10KB，Hash/List/Set/ZSet 元素超 5000 个，或 Hash 总内容超 1MB，都算典型 BigKey。排查要准，删除要稳，否则一个 DEL 就可能让 Redis 卡死几秒，连带业务雪崩。
怎么快速定位 BigKey
生产环境优先用非阻塞、低干扰的方式：
- redis-cli --bigkeys：最常用，自动扫描并返回每种类型中“最大”的那个 Key（比如最大的 String 长度、最大的 List 元素数）。注意它基于 SCAN，会增加 CPU 负载，务必在从库执行，或选凌晨等低峰期运行；加 -i 0.1 可设扫描间隔，缓解压力。
- MEMORY USAGE key：对疑似 Key 精确查内存占用（单位字节），Redis 4.0+ 支持。适合已知 Key 名但不确定大小的场景。对集合类返回的是估算值，可接受但不绝对精确。
- RDB 文件离线分析：用 redis-rdb-tools 工具解析 bgsave 生成的 RDB 快照，不碰线上服务，还能按内存大小排序 Top N，适合深度巡检或事故复盘。
为什么不能直接 DEL
Redis 是单线程，DEL 一个含百万元素的 Hash 或百 MB 的 String，会同步释放全部内存，期间无法处理其他请求。实测中卡顿可达数秒，触发客户端超时、连接池耗尽、主从复制中断，甚至引发哨兵误判切换。
尤其要避开这些操作：
- 在主节点上对大 Key 执行 DEL、RENAME、FLUSHDB
- 用 KEYS * + DEL 组合批量删（KEYS 是全量阻塞命令）
- 未评估 Key 是否还在被业务读写，就贸然清理
安全删除的实操方法
核心原则：**分而治之、渐进释放、可控节奏**。
- Hash 类型：用 HSCAN + HDEL 分批删字段。每次 scan 100 个 field，删完休眠几毫秒再继续，避免打满 CPU 和网络。
- List 类型：用 LPOP / RPOP 或 LTRIM（如 LTRIM key 0 999 保留前 1000 个，其余丢弃）逐步缩小体积。
- Set / ZSet 类型：用 SSCAN / ZSCAN 获取一批成员，再用 SREM / ZREM 删除，同样控制单次数量和间隔。
- String 类型：若确认无用，DEL 风险相对小（无结构遍历），但仍建议在低峰执行，并监控内存回落曲线。
删之前必须确认的事
别只看大小，先判断价值：
- 查监控或日志，确认该 Key 近期是否被访问（如通过 slowlog、monitor 抓包，或 APM 工具追踪）
- 检查业务代码，确认没有定时任务或缓存重建逻辑依赖它
- 如果是用户维度缓存（如 user:123:profile），先查 DB 是否数据已归档或失效
- 删除前做好 RDB/AOF 备份，或在从库验证删除效果
