Redis启动加载RDB时内存开销达文件大小2–3倍，主进程解析构建数据结构、元数据及过期字典，叠加COW与jemalloc碎片（mem_fragmentation_ratio常超1.8），导致RSS飙升；系统vm.overcommit_memory=2会直接fork失败。
会，但不是“恢复过程本身”吃内存，而是恢复前的文件加载阶段瞬间占用大量内存，且极易被误判为“内存泄漏”或“OOM”。
Redis启动时加载RDB文件的内存行为
RDB是二进制快照，Redis启动时会把整个 dump.rdb 文件一次性读入内存，解序列化成对应的数据结构。这个过程不经过渐进式分配，而是按需申请——实际占用内存 ≈ 当前数据集在内存中的真实大小（used_memory），而非RDB文件体积。
- RDB文件压缩后可能只有200MB，但解压还原后可能占1.2GB内存（尤其含大量小字符串、哈希字段时）
- 如果设置了
maxmemory，Redis在加载阶段**不校验内存上限**，直到全部加载完成才开始淘汰逻辑；此时若超限，会直接OOM崩溃 - 使用
jemalloc时，加载期间大量小对象分配易加剧内部碎片，mem_fragmentation_ratio可能从1.2飙升至2.0+
AOF重放阶段的内存增长特征
AOF不是全量加载，而是逐条执行命令重建状态，内存增长更“渐进”，但风险点不同：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 每条命令执行都触发正常内存分配逻辑，所以受
maxmemory和淘汰策略实时约束（不会像RDB那样“一锤定音”） - 但某些命令副作用大：比如
APPEND频繁追加、HSET批量写入哈希、LPUSH大列表，会在重放过程中持续推高内存 - 若AOF中包含大量过期key（未被清理的旧日志），重放时仍会先创建再触发惰性删除，造成瞬时内存尖峰
- 混合持久化（RDB+AOF）重启时，先加载RDB快照，再重放AOF增量——内存压力是两者的叠加
为什么监控看到“恢复后内存比之前还高”？
这不是bug，而是碎片+分配器行为导致的表象：
- RDB加载用的是全新内存页，而运行中更新产生的碎片（尤其
jemalloc的slab管理）在重启后被“重置”，初始mem_fragmentation_ratio往往更低（如1.05） - 但如果你观察的是
used_memory_rss，它包含分配器预留但未使用的内存页；刚加载完RDB时RSS可能虚高，几秒内会回落 - 真正危险的是：如果原实例长期运行已积累严重外部碎片（
mem_fragmentation_ratio> 1.8），重启后虽然RSS下降，但新分配的内存又很快再次碎片化 -
MEMORY PURGE在加载完成后执行有效，但仅对jemalloc生效，且不能回收已被使用的页
最容易被忽略的是：RDB加载不触发 activedefrag，而AOF重放期间该机制默认关闭——碎片整理窗口其实在重启后最需要时反而关着。
