Redis不支持按数据库统计内存占比，因所有DB共享内存池；精准分析需用rdbtools离线解析RDB文件，或逐key调用MEMORY USAGE后按DB聚合。
INFO memory 不显示每个 DB 的内存分布
很多人执行 INFO memory 后发现输出里根本没有按数据库（db0、db1…）拆分的内存数据，只有全局指标如 used_memory 和 used_memory_rss。这是因为 Redis 的内存管理是实例级的，不是按 database 隔离的——所有 db 共享同一块内存池，INFO memory 本身就不提供 per-DB 内存统计。
想看“哪个 db 占得多”，不能靠猜或扫 key，得用更底层的命令或工具。
MEMORY STATS 输出中没有 db_index 字段
MEMORY STATS 返回的是服务器级内存构成，比如 total.allocated、clients.normal、aof.buffer 等，但它**不包含每个数据库的键数量或内存占比**。它的 # Keyspace 段只显示各 db 的键数、过期键数、平均 TTL（例如 db0:keys=123,expires=45,avg_ttl=3600），但不带内存字节数。
所以直接解析 MEMORY STATS 输出无法得到 “db0 占了 12MB” 这类结论。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 它不支持
MEMORY STATS db0这种语法（会报错ERR unknown command） - 它也不接受
db参数，和MEMORY USAGE的行为完全不同 - 如果你在文档里看到 “
MEMORY STATS可查每个库内存”，那基本是误读或过时资料
真正能查每个 DB 内存占用的方法只有两个
Redis 官方没提供直接的 “per-DB 内存用量” 命令，但可通过组合方式逼近：
-
逐 key 统计 + 分库聚合：用
redis-cli --scan --pattern "*"扫出所有 key，再对每个 key 调用MEMORY USAGE <key>，最后按KEYS命令或SCAN的游标结果判断所属 db（需先SELECT db_index切库再 scan）——但注意：这会阻塞主线程，生产环境慎用 -
用 RDB 文件离线分析：停服或 bgsave 后，用
redis-rdb-tools解析 rdb：python rdb -c memory dump.rdb
输出含每 key 的 db、type、size，可按 db 聚合 sum；这是最准、最轻量的方式，适合定期巡检
Python 脚本里调用 r.memory_usage(key) 并按 db 分组，本质也是第一种方式的封装，同样有性能风险——尤其当某个 db 有上百万 key 时，MEMORY USAGE 会逐个评估编码结构（如 ziplist vs hashtable），开销远超 STRLEN 或 EXISTS。
为什么官方不支持 per-DB 内存统计？
因为 Redis 的 database 是逻辑命名空间，不是内存隔离单元。一个 hash 键的 field 存储、一个 list 的节点、一个 set 的 dict entry，都混在同一个内存分配器（如 jemalloc）里，无法在分配时打上 “db0 标签”。MEMORY USAGE 能算单 key，是因为它遍历该 key 底层数据结构并估算；但没机制把所有这些结构反向归属到某个 db 上。
所以别指望未来版本加 INFO memory db0 ——这不是遗漏，是设计使然。真正要定位内存大户，优先用 redis-cli --bigkeys 找 top-N 大 key，再结合业务前缀（如 user:*、cache:order:*）人工归类到对应 db，比强行拆 DB 内存更实际。
