为什么要看分布
用 SCAN 抽样一批键，再逐个 MEMORY USAGE，可以得到这个键空间的内存分布。相比只看排名靠前的大键，分布视角能发现大量中等大小键累积起来的总量，而这正是大键扫描最容易漏掉的一类贡献。
基本信息
| 方法 | SCAN 抽样加逐键 MEMORY USAGE |
|---|---|
| 输出 | 按区间分桶的内存分布直方图 |
| 执行窗口 | 低峰执行并控制速率 |
| 官方工具 | redis-cli --memkeys 与 --bigkeys |
典型使用场景
- 内存告警后判断问题来自少数大键还是大量中键
- 治理方案选型：拆大键还是压中键的数量
- 评估某类业务键的平均占用，用于容量估算
- 新业务上线前预估键规模的增长幅度
- 定期巡检，观察分布形状是否随版本变化
抽样与测量
抽样与测量
redis-cli --scan --pattern 'user:*' | head -100 > sample.txt # 抽样 100 个键
while read -r k; do redis-cli MEMORY USAGE "$k"; done < sample.txt # 逐个测量（示意）
redis-cli --memkeys --memkeys-samples 0 -i 0.1 # 官方工具：按内存口径扫描
redis-cli --bigkeys -i 0.1 # 按元素数口径扫描，作为对照
redis-cli INFO keyspace # 各库键数与过期键统计
# 把测量结果按区间分桶，画直方图，观察分布形状分布形状与治理方向
| 分布形状 | 含义 | 治理方向 |
|---|---|---|
| 少数键极大、其余很小 | 典型的大键问题 | 拆分或迁移大键 |
| 数量多但单个不大 | 数量型中键累积 | 压缩结构、缩短键名、控制过期 |
| 分布平坦 | 数据规模本身很大 | 以容量规划为主，治理空间有限 |
| 分层明显 | 不同业务的键混在一起 | 按前缀分层统计，否则结论被掩盖 |
| 长尾很长 | 存在少量超预期的大键 | 优先排查异常写入 |
抽样必须按前缀分层，不同类型的键混在一起统计会掩盖问题；缓存键与业务持久键的内存行为差别很大。
SCAN 加逐键 MEMORY USAGE 的循环对在线实例有压力，务必限速并在低峰执行，必要时改用 --memkeys 并调低采样量。
分布会随业务变化，单次采样只能描述当时的状态。要下结论，至少取两到三次不同时间点的样本做对比。