AOF加载本质是逐条重放文本命令而非加载快照，需完整执行processCommand流程，包括协议解析、键查找、过期判断等；RDB则直接反序列化插入字典，跳过所有命令执行路径。
加载AOF本质是重放命令，不是“加载”
AOF文件不是数据快照，而是文本命令日志。Redis启动时必须逐条解析并执行每一条命令（如SET、HSET、INCR），走完整processCommand流程：协议解析 → 参数校验 → 键查找 → 过期判断 → 写入键空间 → 模拟响应 → 可能触发淘汰或AOF缓冲写入。哪怕一个INCR counter被写了10万次，就得执行10万次，而RDB里只存counter: 100000这一条反序列化结果。
RDB加载跳过所有命令执行路径
RDB是二进制快照，加载时只做两件事：rdbLoad反序列化 + dictAdd插入字典。它不走命令分发器，不查ACL，不记慢日志，不写AOF缓冲，也不触发任何淘汰逻辑。例如一个10MB的HASH，RDB中可能压缩成2MB二进制块，CPU直接memcpy+指针偏移还原；AOF则要记录上百条HSET，每条都要重新解析协议头*3\r\n$4\r\nhset\r\n...，纯文本体积大、IO多、解析开销线性增长。
混合持久化也不能绕过AOF尾部重放
启用aof-use-rdb-preamble yes后，AOF文件开头嵌入RDB快照（魔数REDIS0011），但加载仍分两阶段：先快速载入preamble部分（等价于RDB加载），再逐条重放尾部增量命令。如果业务写入爆发后未及时bgrewriteaof，尾部可能达百MB，重放仍需数秒——这比纯RDB慢，但比纯AOF（GB级全量重放）快一个数量级。关键指标是redis-cli info persistence | grep -E "aof_current_size|aof_base_size"，比值超过1.5就该触发重写了。
容易被忽略的配置陷阱
以下情况会让AOF加载更慢，且不易察觉：
-
appendfsync always：虽提升安全性，但每次重放命令都强制刷盘，IO放大数倍 -
rdbchecksum yes和rdbcompression yes对AOF加载无影响，但有人误以为关它们能提速——其实只作用于RDB读写 - 旧AOF文件残留且未重写：改了
aof-use-rdb-preamble yes但没执行bgrewriteaof，Redis仍加载旧的纯文本AOF，配置完全无效 - 从Redis Wrong signature trying to load DB from file，而非明确提示版本问题
真正卡住的从来不是磁盘读速，而是命令执行路径本身——这是架构层面的差异，没法靠调优参数抹平。
