RDB文件大小增长需通过定期采集磁盘字节数并打时间戳记录，因Redis INFO命令不提供历史增长数据；须结合stat命令、crontab定时采样，并验证RDB是否实际生成（CONFIG GET save、INFO persistence等），再用rdbtools分析内部构成定位异常增长原因。
直接查 RDB 文件大小并记录时间戳
Redis 本身不提供“RDB 文件历史增长曲线”功能，INFO 命令只返回当前内存快照状态，不记录 RDB 文件的磁盘大小变化。要监控 RDB 文件大小增长趋势，最可靠的方式是定期采集 dump.rdb（或你配置的 dbfilename）在文件系统中的实际字节数，并打上时间戳存档。
操作建议：
- 用
ls -l /var/lib/redis/dump.rdb | awk '{print $5" "$6" "$7" "$8}'提取大小 + 日期（注意：不同系统ls -l字段顺序可能不同，推荐改用stat -c "%s %y" /var/lib/redis/dump.rdb） - 配合
crontab每小时执行一次，把结果追加到日志文件，例如：echo "$(date +%s),$(stat -c '%s' /var/lib/redis/dump.rdb)" >> /var/log/redis/rdb_size.log - 避免在
BGSAVE正在执行时采样——此时dump.rdb可能被重命名（如temp-rewriteaof-*.aof或临时dump.rdb.tmp），导致读取失败或大小为 0
为什么不能只看 used_memory_human 来推断 RDB 大小？
INFO memory 中的 used_memory_human 是 Redis 当前内存中数据的估算体积，但它和最终生成的 RDB 文件大小差异可能极大——RDB 是二进制序列化格式，不含过期时间字段（已过期但未清理的 key 不会写入）、不包含客户端缓冲区、不包含 Lua 脚本缓存，且压缩方式（如 LZF）会影响实际体积。
常见偏差场景：
- 大量带过期时间的 key：内存中存在，但 RDB 不保存过期时间字段，文件反而更小
- 使用了
ziplist编码的小 hash/list/set：内存紧凑，但 RDB 序列化后可能膨胀 2–3 倍 - 启用了
redis.conf中的rdbcompression yes（默认开启）：LZF 压缩会使 RDB 文件显著小于used_memory - 如果
save配置被禁用（如注释掉所有save行），则根本不会生成 RDB 文件，此时谈“增长趋势”无意义
如何确认 RDB 是否真在按预期生成？
光看文件大小不够，得先确保 RDB 持久化机制确实在工作。最容易被忽略的是配置与运行时状态不一致。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
检查步骤：
- 运行
redis-cli CONFIG GET save，确认返回值不是空或""；若返回1) "save" 2) ""，说明 RDB 已被完全禁用 - 运行
redis-cli INFO persistence | grep rdb_，重点关注：rdb_bgsave_in_progress:0（是否正在保存）、rdb_last_save_time（上次成功时间，单位秒）、rdb_changes_since_last_save（自上次以来变更数） - 检查
redis-cli INFO server | grep dbfilename确认实际 RDB 文件名，再用ls -lh核对是否存在且有合理大小（比如几百 MB 而非 0 字节） - 若发现
rdb_last_bgsave_status:err，立刻查 Redis 日志（logfile配置项指定路径），常见错误是磁盘满、权限不足、或dbfilename路径不存在
用 rdbtools 分析单次 RDB 的内部构成
当发现 RDB 文件异常增大（比如一天涨了 2GB），仅看总大小无法定位原因。这时需要解析 RDB 内容结构，找出“谁占得多”。
rdbtools 是最常用的离线分析工具，安装后可快速统计：
-
rdb -c memory /var/lib/redis/dump.rdb > memory.csv：导出每个 key 的类型、编码、大小（字节级估算） -
rdb -c stats /var/lib/redis/dump.rdb：输出整体统计，如 key 总数、各类型分布、平均 key 大小、最大 key 大小 - 注意：
rdbtools的内存估算基于反序列化后对象大小，和MEMORY USAGE结果接近但不等价；它无法反映 AOF 重写或复制缓冲区开销 - 别在生产机上直接跑
rdb -c memory——大 RDB（>10GB）可能吃光内存；建议拷贝到分析机再处理
RDB 文件大小增长本身不是问题，问题在于增长是否匹配业务逻辑。比如某天新增了千万级用户画像 hash，RDB 涨 1.2GB 是合理的；但如果每天固定涨 500MB 且找不到对应写入来源，就要怀疑 key 泄漏或过期失效。
