Redis AOF重写需同时满足aof_current_size≥aof_base_size×(1+percentage/100)且≥min-size，缺一不可；默认100和64mb易致中大型实例每小时多次重写，推荐设min-size为1gb、percentage为80以平衡频率与体积。
默认的 auto-aof-rewrite-percentage 100 和 auto-aof-rewrite-min-size 64mb 在中大型生产实例上基本等于“定时自爆”——每小时重写多次，IO打满、缓冲区溢出、主从延迟飙升都是常态。
为什么两个参数必须同时满足才触发重写
Redis 的 AOF 自动重写是“与”逻辑：只有当 aof_current_size >= aof_base_size * (1 + auto-aof-rewrite-percentage / 100) 且 aof_current_size >= auto-aof-rewrite-min-size 时，才会真正触发。缺一不可。
常见翻车点：
- 把
auto-aof-rewrite-percentage调高到 1000（10 倍才触发），但auto-aof-rewrite-min-size还留着默认64mb→ 小流量实例天天重写 - 反过来，
percentage设成 100，min-size却设成10gb→ 大流量实例 AOF 膨胀到 30GB 也不触发，磁盘直接告警 - 单位写错：
1024是 1024 字节，不是 1KB；必须写1kb、64mb、1gb才生效
怎么定 auto-aof-rewrite-min-size 才不占爆磁盘
这个值不是“越小越好”，而是要匹配你上次重写完的基线体积 aof_base_size。设太小，会导致重写刚完成就又触发，新旧 AOF 文件双份共存，磁盘瞬间翻倍。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
实操步骤：
- 连上 Redis 执行
INFO persistence，找到aof_base_size（单位字节） - 取它的 2–3 倍作为起点：比如
aof_base_size: 524288000（500MB），就设auto-aof-rewrite-min-size 1gb - 如果日均写入约 2GB，推荐直接从
1gb起步；实时计数类场景（写入密集），可设2gb - 严禁设
64mb或1mb—— 这是新手最常踩的坑，不是“下限”，是“值得重写的门槛”
auto-aof-rewrite-percentage 为什么建议调成 80 而不是 100
设成 100 意味着“翻倍就重写”，但 AOF 刚重写完体积最小，高峰期几分钟就涨到 1.8 倍，接着连续触发。而 80 表示“增长 80% 就重写”，相当于在 aof_base_size 基础上多攒 0.8 倍增量再行动，节奏更稳。
适用场景差异：
- 写入稳定可预测（如常规缓存更新）：优先调
auto-aof-rewrite-percentage，min-size设为基线的 1.5 倍 - 写入不规律（如夜间批量导入、活动秒杀）：把
percentage降到 30–50，min-size提高到基线的 3 倍以上，防毛刺误触发 - 观察
INFO persistence中的aof_current_size和低峰期增长速率，取 2–3 小时自然增长量的 1.5 倍反推min-size
真正难的不是算数字，而是理解 aof_base_size 是动态基线——每次重写后它就重置。所以配置不能一劳永逸，得结合业务写入节奏和 INFO persistence 的实际输出来滚动调整。
