auto-aof-rewrite-min-size应设为aof_base_size的2–3倍，而非固定64MB或1MB；它与auto-aof-rewrite-percentage是“与”关系，需同时满足才触发重写，否则易导致磁盘暴增或重写失效。
auto-aof-rewrite-min-size 设太小会吃光磁盘
设成 64mb 或 1mb 是常见误操作。它不是“触发重写的下限”，而是“重写是否值得启动”的门槛——必须同时满足 auto-aof-rewrite-percentage 和该值，才会真正触发重写。如果 aof_base_size（上次重写完的体积）是 500MB，而你把 auto-aof-rewrite-min-size 设成 64MB，那只要 AOF 增长到 564MB 就满足条件；但此时增长量仅 64MB，远未达到“值得重写”的程度，却已生成新文件，旧文件又不会立刻删，瞬间双份共存，磁盘占用翻倍。
正确做法是：登录 Redis 执行 INFO persistence，看 aof_base_size，然后设为它的 2–3 倍。例如 aof_base_size: 524288000（500MB），就设 auto-aof-rewrite-min-size 1gb。
auto-aof-rewrite-percentage 和 min-size 必须配合使用
这两个参数是“与”关系，单独调一个没用。典型翻车场景：
• 把 auto-aof-rewrite-percentage 设成 1000（10 倍才触发），min-size 却设成 64mb → 小流量实例天天重写
• 反过来，percentage 设 100（翻倍触发），min-size 却设 10gb → 大流量实例膨胀到 30GB 也不触发
- 写入稳定、可预测：优先调
auto-aof-rewrite-percentage（如100表示翻倍即触发），min-size设为基线的 1.5 倍 - 写入不规律（如夜间批量导入）：把
percentage降到30或50，min-size提高到基线的 3 倍以上，防毛刺误触发 - 永远用
CONFIG GET auto-aof-rewrite*确认运行时值，配置文件改了不等于生效
重写期间磁盘空间要留够，不是多留 1 倍就够
重写过程是先写新文件，再原子替换。所以峰值占用 ≈ 当前 AOF 文件大小 + 新 AOF 文件大小。而新文件大小≈内存数据序列化后体积（通常比原 AOF 小得多，但不是零）。如果当前 aof_current_size 是 8GB，别只留 8GB 空闲——至少预留 10–12GB，否则重写中途会失败并报错 ERR AOF rewrite failed: No space left on device。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
建议加一条防护：
• 配置 no-appendfsync-on-rewrite yes，避免重写时刷盘争抢 IO
• 把 AOF 文件路径挂载在独立 SSD 分区，不与其他服务混用
• 监控 aof_pending_rewrite 和 aof_delayed_fsync，这两个指标持续非零说明重写或刷盘已成瓶颈
启用混合持久化让重写后体积直接砍半
Redis 4.0+ 支持 RDB-AOF 混合模式，重写时先 dump 出 RDB 快照，再追加增量命令。相比纯文本 AOF，体积通常减少 40%–70%，恢复也更快。启用只需一行：
CONFIG SET aof-use-rdb-preamble yes
注意：
• 必须确保 appendonly yes 已开启
• 混合格式的 AOF 文件头部是 RDB 二进制，后面才是文本命令，不能用 cat 直接读
• 如果你依赖解析 AOF 内容做审计或迁移，启用后需适配解析逻辑
真正难的是判断什么时候该重写、什么时候不该——它取决于你自己的 aof_base_size，而不是文档里写的“推荐值”。每次重写完成后，立刻查一次 INFO persistence 记下新基线，下次配置才有依据。
