AOF文件越变越大是因为持续追加写命令产生大量冗余指令，如重复修改、删除重建、多次增删集合等，导致文件膨胀、恢复慢、磁盘内存占用高。
为什么AOF文件会越变越大
AOF本质是把每个写命令追加进文件，比如SET key1 v1、INCR counter、DEL key1都原样记下来。时间一长，同一key反复修改、删除重建、list/set多次增删，就会产生大量冗余指令。重启时Redis要逐条重放，不仅慢，还占磁盘和内存。
auto-aof-rewrite-min-size 和 auto-aof-rewrite-percentage 怎么设才合理
这两个参数共同决定自动重写的触发时机，但默认值（64mb + 100）在生产环境几乎总是太激进：
-
auto-aof-rewrite-min-size 64mb：64MB对小实例可能够用，但中大型实例往往几分钟就突破，导致频繁重写，加重IO压力 -
auto-aof-rewrite-percentage 100：翻倍就重写，容易在业务高峰期连续触发，尤其当AOF刚重写完又快速增长时
推荐配置（以日均写入量约2GB的实例为例）：
auto-aof-rewrite-min-size 1gb auto-aof-rewrite-percentage 80
这样既避免过早重写，又防止AOF膨胀到3GB以上才行动。注意单位必须带mb或gb，写成1024会被当成字节。
手动执行BGREWRITEAOF前必须确认的三件事
BGREWRITEAOF虽是后台操作，但子进程仍需内存拷贝+磁盘写入，疏忽易引发OOM或IO打满：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 检查剩余磁盘空间是否 ≥ 当前AOF文件大小的1.5倍（重写期间新旧文件并存）
- 用
INFO persistence确认aof_rewrite_in_progress:0，避免并发重写 - 避开流量高峰——重写期间主进程要持续将新写命令写入
aof_rewrite_buffer，若此时QPS突增，缓冲区可能溢出，导致客户端连接超时
安全执行方式：
redis-cli -p 6379 BGREWRITEAOF # 然后立刻观察： redis-cli -p 6379 INFO | grep -E "aof_rewrite|used_memory"
重写后AOF没变小？可能是这些配置被忽略了
即使重写完成，AOF体积仍居高不下，常见原因不是重写失败，而是以下配置未生效：
-
appendfsync no未启用：若仍为everysec，每次重写后的新AOF文件会立即开始高频刷盘，很快又膨胀 - 过期键未真正清理：AOF重写时会跳过已过期但尚未被惰性/定期删除的key，但若
maxmemory-policy设为noeviction，这些“僵尸key”仍在内存里，重写时仍会被写入新AOF - 存在大量
EXPIREAT或PEXPIREAT命令：重写时不会计算绝对过期时间，只保留命令本身，导致新AOF里堆满无效过期指令
验证重写效果最直接的方式是对比重写前后INFO persistence中的aof_current_size与aof_base_size，差值应显著收窄。
真正关键的不是“重写动作是否执行”，而是“重写后的AOF能否稳定在预期水位”。这取决于你是否关掉了无谓的刷盘、是否让过期机制真正起效、以及是否给重写留出了足够冷静的生长周期。
