先说一个几乎所有人都踩过的典型误区：很多人把 aof-use-rdb-preamble yes 当作开启“增量重写”的开关。实际上，这个配置只干了一件事——让重写后的 AOF 文件头部带上 RDB 快照。它解决的是加载速度问题，跟“增量重写”本身的概念压根不是一回事。
真正的增量重写，依赖的是 Redis 7.0 在底层重新设计的 AOF 文件体系。说白了，重写不再是生成一个超大单文件，而是拆成三套班子：base.aof 负责快照打底，incr_*.aof 负责增量日志，再用 manifest.aof 做索引管理。这套新架构虽然默认启用，但想要它跑得顺，下面几个前提条件缺一不可：
aof-use-rdb-preamble yes：这是地基，否则 base.aof 里没有 RDB 快照头，Redis 加载时无法识别。aof-rewrite-incremental-fsync yes：负责控制重写过程中的刷盘频率，防止一次 fsync 把 CPU 卡死（默认就是开启的，切勿关闭）。aof-load-truncated yes：允许 Redis 加载被截断的增量文件，相当于为异常恢复加了一道保险。- 禁用旧式单文件模式：
aof-auto-sync-rewrite这个老参数虽然已废弃，但如果你曾经手动把它设为yes，它仍会偷偷干扰新逻辑。
如何验证当前 AOF 是否走的是多文件增量重写路径
光看配置心里没底？最可靠的办法是亲自验证。手动执行一次 BGREWRITEAOF，然后去 Redis 的数据目录检查文件清单：
ls -1 ./data/base.aofincr_0000000001.aofincr_0000000002.aofmanifest.aof
如果看到了 base.aof、多个 incr_*.aof 和 manifest.aof，恭喜，已经切换到新架构了。如果目录里只有一个孤零零的 appendonly.aof，那就说明还在走老路子——问题八成出在 aof-use-rdb-preamble 没生效，或者 Redis 版本根本没到 7.0（用 redis-server --version 确认一下）。
这里有个重要细节：7.0 之后，appendfilename 这个配置已经作废了。新架构的文件名由 Redis 内部自动管理，你再怎么配置也没用。
重写触发后，aof-use-rdb-preamble 如何影响 base.aof 内容
这个参数直接影响 base.aof 文件的格式。设为 yes 时，base.aof 开头是一段二进制 RDB 快照（开头的 REDIS0011 就是标识），后面才是纯文本的 AOF 命令。Redis 加载时会先像亲妈带娃一样快速解析 RDB 部分，再逐条执行后续命令——又快又准。设为 no 的话，base.aof 就变成纯粹的 AOF 命令流，加载时得一条条回放，不仅慢，还特别容易因损坏而出错。实践中，no 模式下只要有一条命令语法错误，整个加载就挂了；而 yes 模式下，就算尾部 AOF 坏了，RDB 那部分也能稳稳把数据拉回来。
容易忽略的兼容性陷阱
必须警惕的是，Redis 7.0 生成的多文件 AOF，老版本是读不了的。哪怕你把 base.aof 单独拷到 6.x 的机器上，启动时会直接报错：Invalid AOF header 或直接闪退。所以迁移之前，有几件事必须确认：
- 所有哨兵、集群节点以及备份脚本，都需要先升级到 7.0+。
- 监控脚本如果还在检查
appendonly.aof的文件大小，赶紧改为读取INFO persistence里的aof_current_size和aof_base_size。 - 最后也是最重要的一条：
CONFIG GET aof-use-rdb-preamble返回yes，并不代表当前正在运行的 AOF 文件就是混合格式。这个开关只影响下一次重写，存量文件不会自动转换。
最稳妥的推进方法：停机，清掉旧的 appendonly.aof，重启 Redis，再主动触发一次 BGREWRITEAOF，最后检查文件结构。这一步做完，心里就有底了。
