rdb工具是唯一能离线、无侵入、全量解析RDB文件的方式；导出JSON需用rdb --commandjson --escape base64 --db 0 /path/to/dump.rdb避免乱码与数据丢失，内存报告存在jemalloc粒度、ziplist估算偏差及LZF压缩支持等误差源。
直接看 RDB 文件二进制内容没用，必须用 rdb 工具解析才能拿到结构化数据——这是唯一能离线、无侵入、全量分析 Redis 内存和数据构成的方式。
怎么用 rdb 命令导出 JSON 数据
导出是第一步，也是最常被误用的环节。很多人直接跑 rdb --command json dump.rdb，结果发现中文乱码、二进制值丢失、嵌套结构扁平化。
-
--escape raw适合调试：保留原始字节，但需自行处理非 UTF-8 内容 -
--escape base64更稳妥：所有非 ASCII 值转 base64，JSON 解析器能直接读 - 加
--db 0显式指定数据库号，避免多 DB 混合导致 key 冲突 - 路径必须写全，
rdb不自动查找dump.rdb，比如/var/lib/redis/dump.rdb
为什么 rdb --command memory 报告不准
它算的是“序列化后大小 + Redis 内部结构开销”，不是 MEMORY USAGE 的实时值。实际偏差主要来自三处：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 未考虑 jemalloc 分配粒度（比如 1KB 实际占 1.2KB）
- 对 ziplist 编码的 hash/list/set，工具按最大容量估算，而运行时可能远小于该值
- 忽略过期时间字段占用（每个 key 额外 ~16 字节，大量小 key 时不可忽视）
- 若没装
python-lzf，RDB 中 LZF 压缩块会被跳过，导致内存低估
redis-memory-for-key 只能查单个 key？不，它支持通配
这个命令常被当成“线上 debug 工具”，其实它也能离线扫 pattern，只是文档没明说：
-
redis-memory-for-key --key "user:*" /path/to/dump.rdb会匹配所有前缀为user:的 key - 不支持正则，只支持 shell glob（
*、?、[abc]），别写^user - 输出是纯文本，每行一个 key + 内存字节数，可直接
sort -n -k2排序找大 key - 注意：它默认只查 DB 0，跨 DB 要重复执行或写脚本循环
真正容易被忽略的点是：RDB 文件本身可能损坏或版本不兼容——rdb --version 输出的工具版本，和你 Redis 实例生成 RDB 的版本必须匹配（v7+ RDB 需要 rdbtools ≥ 0.1.18），否则解析中途静默失败，连错误都不报。
