开启rdbcompression yes后，rdb文件体积通常能减少30%–70%，具体取决于数据结构；纯小字符串压缩效果明显，而base64等已压缩二进制值几乎不缩水。
Redis RDB 压缩开关实际能减多少体积？
开启 rdbcompression yes 后，RDB 文件体积通常能减少 30%–70%，但具体压缩率取决于数据结构和内容。纯小字符串（如 session ID、短 token）压缩效果明显；而本身已压缩的二进制值（如 base64 图片 blob）几乎不缩水。Redis 6.0+ 默认启用该选项，但升级后配置文件可能仍保留 rdbcompression no，务必检查确认。
LZ4 和 zstd 压缩效果差异大吗？
Redis 7.0+ 支持 zstd，压缩率比默认 LZ4 高 15%–25%，尤其对重复前缀多的 key（如 user:1001:profile, user:1002:profile）更明显。但 zstd 的 fork 子进程耗时略长，高并发写入期间可能轻微抬高延迟。使用前需确认编译时启用了 USE_ZSTD=yes，否则会自动降级到 LZ4 或禁用压缩。
为什么开了压缩，RDB 文件还是很大？
压缩只优化序列化后的写入效率，不解决数据本身冗余问题。常见原因包括：
Redis 8.2.3
下载
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
- 误把临时数据（如
tmp:log:*、cache:batch:*）写入主 DB，用redis-cli --scan --pattern "tmp:*" | wc -l快速排查 - RDB 触发期间发生大量写入：fork 后主进程修改越多，COW 复制的内存页越多，快照体积越大
- 存在“内存大户”：用
MEMORY USAGE key找出单 key 占用超 1MB 的对象，结合业务判断是否可拆分或归档 - save 策略太激进（如
save 60 10000），导致高频小快照堆积，旧文件未清理
如何验证压缩是否真正生效？
不能只看配置项，必须观察生成的文件：
- 执行
redis-cli CONFIG SET rdbcompression yes（热生效，仅影响下次 RDB） - 手动触发
bgsave或等待自动 save 规则命中 - 对比前后
ls -lh dump.rdb*：新文件应明显更小；若大小几乎不变，说明数据本身难压缩或 zstd 未启用 - 检查日志：成功启用 zstd 时，Redis 启动日志会输出
Using zstd compression for RDB
真正决定 RDB 大小的不是压缩算法，而是你存了什么、什么时候存、有没有在存之前清理——KEYS * 和 MEMORY STATS 比 redis.conf 更早暴露问题。
