rdbcompression yes 有用但效果有限，LZF 压缩仅对重复字符串、空值等有效，对随机二进制或已压缩数据基本无效，典型压缩率30%–60%，且仅启动时生效。
Redis RDB 文件太大，rdbcompression yes 真的有用吗
有用，但效果取决于数据特征。LZF 压缩对重复字符串、空值、小整数等敏感，而对随机二进制、已压缩的 value（如 gzip 后的 JSON）、长唯一字符串基本无效，甚至可能略微增大体积。
实操建议：
-
rdbcompression yes是默认开启的，不用手动加；如果关了，RDB 会明显变大，尤其存大量SET或HSET的文本类数据时 - 不要指望它把 2GB 的 RDB 压到 200MB——通常压缩率在 30%–60%，视数据重复度而定
- 验证是否生效：停机后对比
dump.rdb和dump.rdb.bak（关闭压缩后生成）大小，或用file dump.rdb看是否含LZF字样
为什么开了 rdbcompression yes，RDB 还是没变小
常见原因是 value 本身已高度熵化，比如：
- 存了 base64 编码的图片、PDF 片段
- JSON 字段里每个 value 都带时间戳、UUID、加密 token
- 使用了
SET存 protobuf / msgpack 序列化结果
这类数据 LZF 几乎无法压缩，反而因压缩头开销略增体积。此时更有效的是从源头控制：
- 避免在 Redis 存大 Value，改用文件系统 + key 指向路径
- 用
zstd或lz4替代 LZF？不行——Redis 5.0+ 固死用 LZF，不支持换算法 - 检查是否误启用了
appendonly yes，AOF 文件可能比 RDB 更大，混淆判断
rdbcompression no 会导致什么实际问题
主要影响磁盘和网络 IO，不是功能缺陷：
- RDB 备份传输慢：1GB 未压缩文件比 400MB 压缩文件多传 600MB
- 磁盘空间紧张时，
SAVE或BGSAVE可能失败，报错Cannot allocate memory（因写入临时文件需双倍空间） - 主从全量同步耗时增加，从节点加载 RDB 时间变长
- 注意：
rdbcompression no不影响 AOF，AOF 永远不压缩
压缩开关在哪配、配错会怎样
只在 redis.conf 里配，位置靠近 dbfilename 和 dir：
dbfilename dump.rdb dir /var/lib/redis rdbcompression yes
错误配置示例及后果：
- 写成
rdb_compression yes（下划线）→ 启动忽略该行，按默认yes生效，但日志报Unknown configuration parameter - 写在
include引入的子配置末尾 → 被后续同名配置覆盖，以最后出现为准 - 用
CONFIG SET rdbcompression no动态修改 → 不生效，该参数仅在启动时读取，运行中不可改
真正影响体积的从来不是这个开关本身，而是你往 Redis 里塞了什么。压缩只是补救，设计才是关键。
