混合持久化需同时满足：开启aof-use-rdb-preamble yes、启用appendonly yes、保留有效save规则，并手动执行bgrewriteaof生成含redis0011魔数的新aof文件，否则仍全量重放命令。
纯 AOF 模式下 Redis 重启慢，不是因为磁盘读得慢，而是它在“重放”每条命令——哪怕只有 10 万次 SET，也得一条条走完整执行路径。混合持久化（aof-use-rdb-preamble yes）能把它变成“秒级加载 + 少量重放”，但配完参数不触发重写，等于没做。
为什么改了 aof-use-rdb-preamble yes 还是启动慢
这个配置只是告诉 Redis：“下次重写 AOF 时，请在开头塞个 RDB 快照”。它不会动现有 AOF 文件，也不会自动触发重写。你改完配置后，Redis 依然在往旧的纯文本 appendonly.aof 里追加命令，重启时照样全量重放。
- 必须手动执行
redis-cli bgrewriteaof，生成带 RDB preamble 的新文件 - 旧 AOF 文件不会被自动删除或覆盖，仍可能被误用
- 若之前禁用了 RDB（比如把所有
save行删光或设为save ""但没留dbfilename和dir），则 preamble 部分为空，混合失效
如何验证混合持久化真正生效
别只看配置，直接查 AOF 文件头部二进制内容：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 运行
head -c 100 /var/lib/redis/appendonly.aof | hexdump -C - 正确结果开头应含
REDIS0011（RDB 魔数），而不是*2\r\n$6\r\nSELECT这类纯 AOF 文本 - 同时检查
redis-cli info persistence中aof_current_size和aof_base_size，重写后前者应明显小于后者（说明增量部分确实变小了）
切换混合模式必须满足的三个硬性条件
缺一不可，否则要么启动失败，要么回退到纯 AOF 路径：
-
appendonly yes：AOF 必须启用 - 至少一个有效
save规则（如save 900 1）或显式save ""—— 目的是保留 RDB 能力，不能删掉dbfilename和dir - 执行过
bgrewriteaof，且确认其完成（aof_rewrite_in_progress:0）
容易被忽略的兼容性与故障点
混合持久化不是“开箱即用”，几个边界情况必须人工确认：
- Redis 版本低于 4.0？配置会被静默忽略，启动时报
Wrong signature trying to load DB from file - AOF 文件损坏发生在 preamble 区域？Redis 可能无法跳过，直接启动失败
- 从旧版升级后首次启用，没手动触发
bgrewriteaof？老 AOF 文件无 preamble，加载仍走纯 AOF -
auto-aof-rewrite-percentage被禁用或设得过高？AOF 长期不重写，尾部膨胀，混合优势归零
最常被跳过的动作是：改完配置后没执行 bgrewriteaof，或者执行了但没验证新文件是否真含 RDB 魔数。只要 preamble 没落盘，再好的配置也白搭。
