小Key内存浪费主因是每个Key约90–100字节固定元数据开销远超几字节有效数据，导致载荷占比常低于5%；Hash合并可共享元数据并用listpack/ziplist紧凑存储，节省50%~70%内存，但需规避字段过多阻塞、命名过长、跨域合并等风险。
因为每个小Key都要扛住约90–100字节的固定元数据开销，而实际存的数据可能只有几个字节——内存几乎全被“管理费”吃掉了。
小Key的元数据开销远超数据本身
Redis为每个Key分配内存时，不只是存value，还要维护：redisObject结构（16字节）、键名字符串（含长度+空终止符）、底层数据结构封装（如dictEntry，通常32字节以上）、以及内存分配器本身的对齐和碎片损耗。实测中，一个SET user:1001:name "zhangsan"（键+值共约20字节）实际占用内存常达110字节以上。
- 当业务批量写入千万级用户配置项（如
feature:user:1001:dark_mode、feature:user:1001:notify_sound），每个Key只存"true"或"false"，有效载荷占比往往低于5% - Redis无法复用这些元数据，每个Key都独立申请内存块，加剧分配器碎片
-
INFO memory里mem_allocator显示jemalloc时，allocator_frag_ratio常飙升到1.8+，说明大量小空闲块无法合并使用
为什么Hash能显著改善小Key场景
把分散的多个小Key收拢进一个HASH，元数据只算一份，而字段（field）以紧凑方式存储在ziplist或listpack中——没有额外指针、无字符串头开销、支持前缀压缩。
- 例如：将10个
user:1001:*字符串Key合并为HSET user:1001 name "zhangsan" age 20 city "shanghai" ...，内存可节省50%~70% - 但注意：
HGETALL会一次性拉出全部字段，若字段数过多（如>1000）仍可能阻塞；建议用HGET按需取单个字段 - Redis 7.0+默认启用
listpack，比老版ziplist更省内存且无连锁更新风险
别忽略key命名本身也在吃内存
Key名不是“免费”的——它参与哈希计算、存在dict表中、也受内存分配器管理。过长或重复前缀会直接放大浪费。
- 避免
user_profile_basic_info_v2_field_name_1001这类命名，缩成u:1001:pb或u1001pb（只要全局唯一且可读即可） - 同一业务域下尽量统一前缀长度，比如全部用
u:而非混用user:、usr:、u:，减少dict哈希桶分裂概率 - 用
MEMORY USAGE keyname实测验证：一个u:1001:name比user:1001:name在百万量级下能省下几十MB
真正卡住内存利用率的，往往不是大Value，而是成千上万没被意识到的“小Key税”。改结构比加内存更治本，但得同步检查应用层是否依赖单Key原子性或TTL粒度——这些才是落地时最容易翻车的地方。
