大 key 检测怎么做
大键检测有两条互补的路径：抽样扫描（--bigkeys 按元素数量、--memkeys 按内存）负责发现面，定点核查（MEMORY USAGE、STRLEN、SCARD 等）负责确认点，业务侧埋点负责抓住新增的大键。三者结合才能同时覆盖存量和增量。
基本信息
| 扫描手段 | redis-cli --bigkeys、redis-cli --memkeys |
|---|---|
| 定点手段 | MEMORY USAGE、STRLEN、LLEN、SCARD、HLEN、ZCARD |
| 埋点手段 | 客户端记录超大请求与超大响应体 |
| 执行位置 | 从库或低峰执行，集群需要对每个分片分别扫描 |
| 口径提醒 | 元素个数与内存占用是两件事，分别测量 |
典型使用场景
- 例行巡检：按周或按迭代扫描一次，形成键规模基线
- 延迟尖峰复盘：核对出事时间窗内是否有大键被整体操作
- 新业务准入：上线前确认设计方案里没有大键形态
- 内存估算：用真实大键样本校准容量模型
- 批处理前评估：批量删除或全量遍历之前先摸清规模
- 归档迁移：找出应该外置到对象存储的大值
扫描与核查
扫描与核查
redis-cli --bigkeys -i 0.1 # 按元素数量扫描，带间隔降低压力
redis-cli --memkeys -i 0.1 # 按内存占用口径扫描
redis-cli -h replica-host -p 6379 --bigkeys # 从库执行，减少对主库影响
redis-cli MEMORY USAGE suspect:hash SAMPLES 0 # 大键精确测量（全量采样）
redis-cli HLEN suspect:hash # 字段数量确认集合规模
redis-cli STRLEN suspect:string # 字符串键确认长度
redis-cli LINDEX suspect:list 0 > /dev/null # 顺带确认键与类型是否匹配手段对照
| 手段 | 口径 | 优点与局限 |
|---|---|---|
| --bigkeys | 元素个数或字符串长度 | 快，但看不出元素自身的大小 |
| --memkeys | 单键内存占用估算 | 更贴近内存风险，仍是采样口径 |
| MEMORY USAGE | 单键内存，可控制采样精度 | 精确但需要逐键调用 |
| 业务埋点 | 请求与响应体积 | 能抓新增大键，需要改客户端代码 |
| SLOWLOG | 现场命令证据 | 能看操作方式，不能量化规模 |
扫描是抽样口径：元素多的键会被优先报出，但真正吃掉内存的可能是元素不多、单个元素很大的键，两种口径都要看。
大键治理的顺序通常是先拆分、再改访问方式、最后考虑外置：只拆不改，业务仍然会按整体读写，问题只是换了个键名。