aof暴增源于其按协议原样追加写命令的设计，不感知语义、不合并操作；重写需同时满足auto-aof-rewrite-percentage和auto-aof-rewrite-min-size，且依赖真实写入触发；bgrewriteaof fork子进程生成新文件，需双倍磁盘空间与额外内存。
因为AOF不是存数据快照，而是逐条记录所有写命令——哪怕一个key被覆盖100次，它就记100行；哪怕一次LPUSH塞5个元素，它就拆成5条命令追加。这不是bug，是设计使然。
为什么SET/INCR/LPUSH这类操作会让AOF暴增
AOF按协议格式原样追加命令文本，不感知语义，也不做合并。比如对同一个counter执行1000次INCR，AOF里就是1000行*2\r\n$4\r\nINCR\r\n$7\r\ncounter；而LPUSH list a b c d e在AOF中实际被拆解为5条独立LPUSH命令。
- 大value写入（如20KB JSON）会直接放大AOF体积，因为整个value字符串被原样写入
-
EXPIRE/DEL类命令也会被记录，即使对应key后续已不存在，它们仍占空间 - 没有“删除中间态”的机制：AOF只管追加，从不清理旧命令，除非重写
auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size 为什么常失效
这两个参数必须同时满足才触发重写，但很多人配了却没反应，核心原因是：aof_current_size初始为0，且Redis只在有真实写入后才开始计算增长百分比。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 刚启动的实例若没执行过任何写命令（连
SET a b都没有），aof_current_size始终是0，百分比无意义 - 配置写在
redis.conf里，但运行时没执行CONFIG REWRITE，重启后就丢失 -
auto-aof-rewrite-min-size设太小（如16mb）会导致即使增长200%，因未达下限也不触发 - 检查是否真生效：用
CONFIG GET auto-aof-rewrite*，别只看配置文件
重写期间磁盘和内存为啥突然告急
BGREWRITEAOF不是复制粘贴，而是fork子进程遍历内存生成新AOF——这过程对资源有硬性要求。
- 磁盘空间必须 ≥ 当前
appendonly.aof大小的2倍：旧文件继续追加，新文件同时生成 - 内存可能翻倍：主进程大量修改大key时，写时复制（COW）会把共享页拷贝一份给子进程
- 若看到
Can't rewrite append only file: No space left on device，不是磁盘满，而是重写时临时空间不足 - 建议搭配
no-appendfsync-on-rewrite yes，避免重写期间fsync加剧IO压力
最易被忽略的一点：重写后AOF变小，不代表数据丢了——它只保留最终存活的key及其值，所有中间状态、已过期或已删除的key都不会进新文件。但这也意味着，如果你依赖AOF里某条EXPIRE命令的时间点做业务逻辑，那重写后这个信息就没了。
