合理值应基于aof_base_size动态设定，建议设为其实值的2～3倍（如aof_base_size为500mb，则min-size设1gb～1.5gb）；percentage生产环境推荐50～100（基线大时）或20～30（突增时），设0可禁用自动触发。

auto-aof-rewrite-min-size 设多少才算合理

不能直接设成 64mb 或 1gb 这类固定值——它必须和你实例当前的 aof_base_size 挂钩。查一次 INFO persistence，看 aof_base_size 是多少（比如 524288000 字节 ≈ 500MB），再乘以 2～3 倍，得到目标值：1048576000（1GB）或 1572864000（1.5GB）。设小了会高频重写，磁盘瞬间双倍占用；设大了可能 AOF 胀到 20GB 也不触发，加载慢、备份卡死。

auto-aof-rewrite-percentage 怎么调才不踩坑

默认 100 在小文件场景下极危险：若 aof_base_size 是 10mb，增长到 20mb 就触发，IO 压力叠加。生产环境建议：

• 写入稳定、基线大（>500MB）：设 50～100
• 写入突增明显（如秒杀压测后）：临时调低到 20～30，但必须同步盯 aof_rewrite_duration_sec
• 想彻底规避自动触发风险：直接设为 0，靠运维在凌晨手动跑 BGREWRITEAOF

为什么改了配置还不生效

常见失效原因不是配置写错，而是状态没对齐：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• aof_base_size 为 0：说明从未成功重写过，自动机制压根不启动——先手动执行一次 BGREWRITEAOF
• 改完 redis.conf 没执行 CONFIG REWRITE 或重启：运行时值仍是旧的，用 CONFIG GET auto-aof-rewrite-min-size 确认
• aof_rewrite_in_progress 为 1：重写正在进行中，新配置要等这次结束才参与下次判断
• 重写失败过一次：aof_base_size 不会更新，后续所有自动判断都失效，得人工介入

手动重写时，min-size 和 percentage 起不起作用

完全不起作用。BGREWRITEAOF 是强制命令，绕过全部阈值判断。但它仍受三重硬约束：

• 磁盘剩余空间必须 ≥ 当前 aof_current_size 的 1.2 倍（重写期间新旧文件共存）
• 内存需足够 fork 子进程（Can't fork for AOF rewrite 日志即表示失败）
• 若 no-appendfsync-on-rewrite 为 yes 且主线程正执行 fsync，重写会被延迟调度（aof_rewrite_scheduled 为 1）

真正难控的从来不是“怎么设阈值”，而是 aof_base_size 一旦冻结就再也拉不回来——这个值只在重写成功时更新，失败一次，整个自动机制就瘫痪了。