调低 auto-aof-rewrite-percentage 会提高重写频率，因其阈值降低；真正降低频率需调高该值或同步增大 auto-aof-rewrite-min-size，并结合手动触发与业务场景优化。
调低 auto-aof-rewrite-percentage 本身不能直接“降低”重写频率，反而会提高频率；真正降低频率，得调高它，或配合 auto-aof-rewrite-min-size 一起压住触发条件。
为什么调小 auto-aof-rewrite-percentage 反而更频繁？
这个参数不是“增长多少就重写一次”，而是“比上次重写后的大小增长了 X% 就触发”。比如设为 80，AOF 从 100MB（上次重写后）涨到 180MB 就满足条件；设为 150，就得涨到 250MB 才触发。数值越小，门槛越低，自然更容易撞上。
常见错误现象：把参数从默认 100 改成 50 后，发现每天重写三四次，temp-*.aof 文件堆满目录，Redis 进程 CPU 短时飙升。
- 它只在 AOF 文件大小 >
auto-aof-rewrite-min-size时才参与判断 - 它对比的基准是“上次重写完成后的 AOF 大小”，不是初始大小，也不是当前 RDB 大小
- 如果重写中途失败（如磁盘满、OOM），基准值不会更新，下次仍按旧基准计算，可能误触发
哪些场景适合调高 auto-aof-rewrite-percentage？
目标是减少重写次数，核心思路是拉宽两次重写之间的增长空间，尤其适用于写入节奏稳定、数据变更不剧烈的业务。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 低频写入服务（如配置中心、权限缓存）：可设为
150或200，让文件增长到 2–3 倍再重写 - HDD 存储环境：重写过程涉及大量顺序读+顺序写，IO 延迟高，应尽量减少触发次数，建议 ≥
120 - 内存紧张但磁盘充足：重写会 fork 子进程，内存占用瞬时翻倍；若已接近
maxmemory，宁可接受稍大 AOF，也别让重写引发 OOM
auto-aof-rewrite-min-size 必须同步调大
只调高百分比还不够。如果 AOF 刚过 64MB（默认值），哪怕百分比设成 200，只要涨到 192MB 就又触发了——实际只撑了 128MB 增长空间。这时必须把下限也抬高。
- SSD + 写入量中等：可设
auto-aof-rewrite-min-size 128mb，配合auto-aof-rewrite-percentage 120 - HDD + 高内存实例（32G+）：建议
auto-aof-rewrite-min-size 256mb，避免小文件反复重写消耗 I/O - 注意：该值不是“重写后目标大小”，而是“启动重写的最低门槛”，设太大会导致长期不触发（例如写入极少，AOF 卡在 63MB 不动）
手动触发比自动更可控
当业务有维护窗口、或监控发现 AOF 持续膨胀但尚未达阈值时，用 BGREWRITEAOF 主动干预，比依赖自动机制更稳妥。
- 执行前先看
INFO persistence中的aof_current_size和aof_base_size，算出实际增长比例 - 避免在主从切换、RDB save 并发时执行，防止子进程竞争资源
- 重写期间
aof_rewrite_in_progress为1，可通过此指标做自动化巡检
真正决定重写频率的，从来不是单个参数，而是 auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size 的组合效果，再加上你对重写时机的实际掌控力。忽略后者，光调前者，等于只拧松了油门却没碰刹车。
