RDB 文件加载比 AOF 快，因 RDB 是二进制快照，仅需反序列化+字典插入；AOF 是文本命令流，须逐条执行完整命令流程，路径更长、开销更大。
为什么 RDB 文件加载比 AOF 快
RDB 是二进制快照，Redis 启动时直接 rdbLoad 解析整个文件，一次性把所有键值对还原进内存字典结构；而 AOF 是文本命令流，必须逐条执行 redisCommand（比如 SET、LPUSH），每条都走完整命令解析、校验、执行、响应流程。即使启用 aof-use-rdb-preamble yes 的混合模式，也只是在 AOF 开头嵌入一段 RDB 数据，主体仍需重放命令。
实际加载耗时差异在哪
关键不在“文件大小”，而在“执行路径长度”：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- RDB 加载：跳过命令分发、ACL 检查、慢日志记录、AOF 缓冲写入等环节，只做数据反序列化 + 字典插入
- AOF 加载：每条命令都要经过
processCommand全流程，包括参数校验、key 查找、过期判断、持久化写入（如果 AOF 还开着）、甚至可能触发淘汰策略 - 当数据量大（比如 10GB+）且存在大量小 key（如 session）时，AOF 加载可能比 RDB 多花 3–5 倍时间
哪些配置直接影响 RDB 加载速度
rdbchecksum yes 和 rdbcompression yes 是默认开启的，但它们对加载阶段有真实影响：
-
rdbchecksum：加载时会计算 CRC64 校验和，校验失败则拒绝加载 —— 安全但多一次全量扫描，大数据集可考虑关掉（仅限可信环境） -
rdbcompression：LZF 压缩让文件更小，但加载时需解压 —— 如果磁盘 I/O 不是瓶颈（比如用 NVMe），关掉它反而减少 CPU 解压开销 -
io-threads-do-reads yes（Redis 6.0+）：允许用 IO 线程并行读取 RDB 文件，但注意：RDB 解析本身仍是单线程，仅加速磁盘读取阶段
容易被忽略的冷启动陷阱
很多人以为只要 dump.rdb 存在，重启就一定快 —— 实际上：
- 如果
dir配置路径不存在或权限不足，Redis 会静默跳过加载，启动后是空实例（INFO persistence中loading为 0，但rdb_last_bgsave_status可能是ok，迷惑性很强） - 若 RDB 文件损坏（比如被截断），Redis 默认不报错退出，而是打印 warning 并继续启动 —— 表现为部分数据缺失，且无明确提示
- 使用
SELECT切换数据库的场景下，RDB 文件只保存当前选中的 db（通常是 db0），其他库的数据不会被快照 —— 这不是 bug，是设计行为
