用 rdb -c memory 可离线解析 RDB 文件，按数据库分组输出键数、总内存和平均键大小，精准统计各 db 内存占比，支持 CSV 导出与前缀聚合分析。
怎么用 rdbtools 解析 RDB 文件看各 db 的内存占比
直接跑 rdb -c memory 就能按数据库分组输出键数量、总内存、平均键大小，这是最接近你需求的命令。它不依赖 Redis 实例运行状态，纯离线分析 RDB 文件，适合线上 dump 后做容量审计。
常见错误是直接在 Redis 进程还在写入时拷贝 RDB——可能损坏或不一致；必须停写、或用 redis-cli --rdb 触发安全快照，再拿那个文件分析。
-
rdb -c memory /path/to/dump.rdb > memory_report.csv：输出 CSV，可用 Excel 或 awk 处理 - 加
--db 0可只看某一个库（比如只查db 0的热点 key） - 默认单位是字节，加
--bytes才显示原始字节数，否则是带 K/M/G 的可读格式 - 如果 RDB 是压缩格式（Redis 7.0+ 默认启用），
rdbtools从 v0.1.15 起才支持，旧版本会报错Invalid RDB format
为什么 INFO keyspace 不够用
Redis 自带的 INFO keyspace 只返回每个 db 的 key 数量（keys=1234,expires=567），完全不体现 value 大小、编码类型、内存开销。一个 db 1 有 10 万个 string 键，和 10 万个 hash（每个含 50 字段），内存差 10 倍以上，但 INFO 看不出区别。
更麻烦的是：有些业务把不同模块混在一个 db，靠 key 前缀区分（比如 order:123、user:456），这时光看 db 编号毫无意义，必须进一步按 pattern 统计。
-
rdb -c memory输出里有database、type、key、size_in_bytes字段，可 pipe 给awk或csvsql按前缀聚合 - 例如统计所有
cache:开头的 key 占比：rdb -c memory dump.rdb | awk -F',' '$3 ~ /^"cache:/ {sum += $5} END {print sum}' - 注意：
size_in_bytes是估算值（基于编码+字符串长度），对 list/zset 等结构可能偏低，但趋势可靠
rdbtools 安装和兼容性避坑点
别用 pip install rdbtools —— 那是另一个同名废弃项目（2014 年停更）。正确包是 rdbtools-ng，作者是 sameer，GitHub 主页明确写着 “Next Generation”。装错会导致命令不存在或解析失败。
- 安装：
pip install rdbtools-ng（Python 3.7+，macOS/Linux 推荐，Windows 需先装 Visual Studio Build Tools） - 验证是否装对：
rdb --version应输出类似rdbtools-ng 0.1.18 - Redis 6.0+ 的 RDB 若启用了
active-expire或lfu计数器，老版本rdbtools-ng（ - 大文件（>2GB）解析时内存占用高，加
--stream参数可流式处理，避免 OOM
生成可视化报告的关键字段怎么筛
CSV 输出里真正影响业务库占比判断的是三列：database（db 编号）、size_in_bytes（该 key 内存）、type（数据结构）。别被 encoding 或 expiry 分散注意力——除非你在查过期策略问题。
容易忽略的是：Redis 的 db 编号从 0 开始，但很多业务只用 db 0 和 db 1，其他空 db 在报告里也占一行（size=0），直接 sum 会多出干扰项。得先过滤掉 size 为 0 的行。
- 快速统计各 db 总内存（shell）：
rdb -c memory dump.rdb | awk -F',' '$5 > 0 {db[$2] += $5} END {for (i in db) print "db" i ": " db[i] " bytes"}' | sort - 想导出带百分比的表格？用 Python pandas 更稳：
df = pd.read_csv("memory_report.csv", names=["database","type","key","encoding","size_in_bytes","expiry"]); df.groupby("database")["size_in_bytes"].sum().pipe(lambda x: x / x.sum() * 100) - 如果发现某个 db 的
size_in_bytes异常高但 key 数很少，大概率是 bigkey（比如一个 50MB 的 hash），这时要配合rdb -c protocol抽样看具体 key 内容
实际跑下来，最耗时间的不是解析，而是确认 RDB 文件是否干净、有没有被截断、以及业务方自己对“库”的定义是否真和 Redis 的 db 编号对齐——有时候他们说的“订单库”其实分散在 db 0（缓存）和 db 2（临时队列）里。
