什么时候缩容
键被大量删除后，主字典的装载率会下降。装载率低于约 10% 时 Redis 触发缩容，把哈希表迁移到更小规格，释放出的内存以台阶形式回落。缩容与扩容共用同一套渐进式 rehash 机制，所以不会一次性完成，删除后内存往往要过一段时间才降下来。
基本信息
| 缩容触发 | 装载率低于约 10% |
|---|---|
| 扩容触发 | 装载率约 1.0，后台保存期间放宽到约 5.0 |
| 实现机制 | 渐进式 rehash，分批迁移 |
| 观测特征 | 内存台阶式回落 |
典型使用场景
- 批量清理数据后内存没有立即回落，确认是否属于正常节奏
- 内存水位长期偏高，评估能否通过清理冷数据回收
- 排查内存曲线呈锯齿状的成因
- 压测结束后清空数据，观察内存是否回到基线
- 容量规划：预估一次批量删除能释放多少
观察回落过程
观察回落过程
redis-cli DBSIZE # 删除前后的键总数对比
redis-cli INFO memory | grep -E 'used_memory_human|used_memory_peak_human'
redis-cli INFO memory | grep -E 'mem_fragmentation_ratio' # 碎片率是否变化
redis-cli MEMORY STATS | grep -E 'overhead|dataset' # 字典等开销是否下降
redis-cli DBSIZE # 确认删除已生效，再隔一段时间看内存
redis-cli --scan --pattern 'demo:prefix:*' | head -5 # 抽样确认键确实已被删除现象与判断
| 现象 | 原因 | 怎么判断 |
|---|---|---|
| 删除后内存不降 | 缩容是渐进的，分配器也未必立刻把页还给系统 | 等一段时间再比对，不要立刻定性 |
| 内存台阶式下降 | 字典缩容与内存页释放分批发生 | 属正常现象 |
| 装载率长期在中位徘徊 | 扩容与缩容在阈值间往返 | 关注是否有反复的批量写入与删除 |
| 碎片率偏高 | 释放后页未归还，形成外部碎片 | 可评估 activedefrag 是否适用 |
| used_memory_peak 不降 | 峰值指标记录的是历史最高点 | 不要拿它判断当前是否回收 |
缩容同样走渐进式 rehash，字典越大过程越久。期间查询性能没有明显变化，但 CPU 会有轻微抬升，属于预期行为。
mem_fragmentation_ratio 是 RSS 与 used_memory 的比值，大于 1 说明 RSS 高于逻辑使用量，可能来自碎片或未归还的页；它本身不等于内存泄漏。
大批量删除与大批量写入交替出现时，字典会反复扩容缩容，内存曲线呈锯齿形。若这种模式长期存在，应考虑调整写入模式而不是只看曲线。