RDB文件过大的核心原因是未启用压缩或数据冗余高；开启rdbcompression和rdbchecksum并优化save策略可减容30%–70%，同时需治理冗余数据、避免大写入期间持久化及精简key设计。
RDB 文件太大，核心原因通常是未启用压缩或数据本身冗余高；开启 rdbcompression 和 rdbchecksum 配合合理 save 策略，能直接减少 30%–70% 磁盘占用。
为什么 RDB 文件会异常大？常见诱因有哪些
RDB 是内存快照的二进制序列化结果，体积直接受原始数据量、编码方式和压缩配置影响。不启用压缩时，rdbcompression no（旧版默认）会让字符串、哈希等结构以明文形式存储，尤其含大量小字符串或重复前缀的 key 时，膨胀非常明显。
- Redis 6.0+ 默认开启
rdbcompression yes，但升级后配置文件可能保留旧值，需手动确认 -
rdbchecksum yes虽增加少量写入开销（约 1%），但能防止传输损坏，且不影响体积；关掉它不会减小文件，反而有风险 - 如果用了
zstd压缩（Redis 7.0+），需确保编译时启用了USE_ZSTD=yes，否则回退到lz4或直接禁用
如何安全启用 RDB 压缩并验证效果
修改 redis.conf 后必须重启或 CONFIG REWRITE 持久化配置，再触发一次 SAVE 或等待自动 save 规则命中，才能生成新压缩文件。
- 设置
rdbcompression yes（启用 LZ4，默认）或rdbcompression zstd（Redis 7.0+，压缩率更高） - 保持
rdbchecksum yes（不建议关） - 执行
redis-cli CONFIG SET rdbcompression yes可热生效，但仅对下次 RDB 生效；旧文件仍存在，需手动清理 - 对比前后体积：
ls -lh dump.rdb*，典型场景下zstd比lz4再小 15%–25%，但 fork 耗时略长
光靠压缩不够：配合 save 策略和数据治理降体积
压缩只能优化单次快照效率，若数据中存了大量过期不用的 key、冗余日志或未清理的集合，RDB 始终会“背锅”。真正压降体积要从源头入手。
- 检查是否误将临时数据（如 session、缓存日志）写入主 DB：用
redis-cli --scan --pattern "tmp:*" | wc -l快速探查 - 避免在 RDB 期间做大规模写入：
save触发时 fork 出的子进程会 copy-on-write，写越频繁，RDB 文件越大（因为要保存 fork 时刻的完整内存副本） - 精简
save配置：例如把save 900 1改为save 3600 1000，减少高频小快照堆积；配合 AOF + RDB 混合持久化可进一步降低 RDB 频率 - 定期用
MEMORY USAGE key找出“内存大户”，结合业务判断是否可拆分、归档或改用流式结构（如用Stream替代大 Hash）
压缩开关只是开关，真正决定 RDB 大小的是你存了什么、什么时候存、以及有没有在存之前清理。别只盯着 rdbcompression，KEYS * 和 MEMORY STATS 往往比配置文件更有说服力。
