首选 redis-cli --bigkeys 扫描 bigkey，因其基于 scan + 类型命令非阻塞探查；禁用 keys *，因其 o(n) 全量遍历会阻塞主线程导致服务中断。
生产环境扫描 bigkey，首选 redis-cli --bigkeys，它不阻塞主线程，能快速定位风险类型和 Top 大 Key。
为什么不能用 KEYS *
执行 KEYS * 会遍历整个键空间，时间复杂度 O(N)，在千万级 key 的实例上可能卡住 Redis 主线程数秒甚至十几秒。所有后续请求排队超时，监控告警、主从心跳中断、连接池打满都可能发生。这不是“慢”，是服务级中断。
- 它不是“查得慢”，是“不让别人查”
- 哪怕只加个
KEYS user:*，只要匹配 key 数量大，一样阻塞 - 任何带通配符的
KEYS命令，在生产环境都应视为禁用命令
redis-cli --bigkeys 是怎么工作的
redis-cli --bigkeys 底层用的是 SCAN + 类型命令组合（如 STRLEN、HLEN、LLEN），每次只取少量 key 批量探查，不锁主线程，也不加载全量数据到内存。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 默认阈值：
String > 10KB、集合元素数 > 1000；可加--bigkeys -i 0.1控制扫描间隔（单位秒），降低对业务影响 - 输出包含每种结构的最大 Key、平均大小、元素数，以及 Top 几个最可疑的 Key
- 它不返回精确字节数（比如 Hash 总体积需
MEMORY USAGE补充），但足够用于初筛
需要更准？用 MEMORY USAGE 配合 SCAN 脚本
当 --bigkeys 提示某个 hash:order:2026 很大，但你不确定是否真超 1MB，就得用 MEMORY USAGE 精确测量。注意：这个命令本身是 O(N) 的，不能对每个 key 盲扫，必须先缩小范围。
- 先用
SCAN拿一批疑似 key：SCAN 0 MATCH "hash:order:*" COUNT 500 - 对返回的每个 key 执行
MEMORY USAGE <key></key>，只测这批，避免全量扫 - Python 示例片段（非完整脚本）：
cursor = 0<br>while cursor != '0':<br> cursor, keys = r.scan(cursor, match='hash:order:*', count=100)<br> for k in keys:<br> size = r.execute_command('MEMORY USAGE', k)<br> if size > 1048576: # >1MB<br> print(f'{k} → {size} bytes') - 别在高峰时段跑；
MEMORY USAGE对大 Hash/List 仍有一定开销，单次调用不阻塞，但高频调用会累积压力
容易被忽略的三个点
第一，--bigkeys 不识别嵌套结构——比如一个 String 存的是 JSON 数组，它只看字符串长度，不解析内容；第二，集群环境下，它默认只连一个节点，要扫全集群得写循环连各分片；第三，有些 bigkey 是“动态膨胀”的（比如日志类 List 不断 LPUSH），扫描结果只是快照，得结合监控（如 mem_fragmentation_ratio 突增、evicted_keys 上升）交叉验证。
