大量小Key推高Redis内存主因是每key约70–100字节固定元数据开销；前缀压缩仅缩短键名、不减key数量，效果有限（节省<15%）；最优解是用HASH合并逻辑相关小Key，共享元数据并利用listpack/ziplist紧凑存储，但需规避命名过长、跨域合并、HASH膨胀卡顿及KEYS失效等风险。
大量小Key会显著推高Redis内存占用，不是因为数据本身大，而是每个key都带着约70–100字节的固定开销（redisObject + dictEntry），再加上键名长度、哈希表指针、内存碎片等。前缀压缩不能真正减少元数据数量，它只是让键名变短——治标不治本；真正有效的做法是合并存储。
为什么前缀压缩效果有限
键名缩短确实能省点内存，比如把user:profile:12345缩成u:p:12345，从21字节降到9字节，但相比每个key固有的70+字节开销，节省比例通常不到15%。更关键的是：前缀压缩不减少key的总数量，dict哈希表的桶数组、冲突链、rehash负担、遍历耗时全都没变。一旦key总数超千万，即使全是短key，used_memory和used_memory_rss也会快速攀升，碎片率容易突破1.5。
用Hash合并小Key是最直接的解法
把一批逻辑相关的key（比如同一用户的多个配置项）塞进一个HASH，共享同一个redisObject和dictEntry，只消耗一份元数据。底层在元素少、值小时自动用listpack（Redis 7.0+）或ziplist（旧版），紧凑序列化，内存密度极高。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 示例：原来存100个
user:12345:setting:theme、user:12345:setting:lang……共100个String key → 改为一个HASH：HSET user:12345:settings theme dark lang zh-CN notifications true - 注意：
HASH字段无法单独设TTL，整个key只能统一过期。若某些字段生命周期差异极大（如theme长期不变，otp_code5分钟失效），得拆组或在应用层兜底刷新 - 别用
HASH存超大字段（单个field > 1KB）或超多字段（> 1000），否则可能触发编码降级到hashtable，反而更费内存
合并时必须避开的三个坑
合并不是无脑HSET就完事，这几个边界条件不处理，轻则白优化，重则引发雪崩：
-
HASHkey命名仍要短：别写user_profile_settings_v2_for_mobile_app_12345，缩成u:12345:s，否则单个key的redisObject开销还在 - 避免跨业务域合并：用户设置和订单状态不该塞进同一个
HASH，否则一次HGETALL拉回无关数据，网络和CPU都浪费 - 警惕
HASH膨胀后无法渐进式rehash：当HASH从listpack升级为hashtable时，如果该key访问极热，单次HGET可能卡住主线程几十毫秒——用redis-cli --bigkeys定期扫描，对字段数>500或总大小>10KB的HASH做分片（如u:12345:s:1、u:12345:s:2）
最易被忽略的一点：合并后，所有依赖KEYS user:*:settings这类模式匹配的运维脚本或监控逻辑都会失效。必须同步改用SCAN + 应用层过滤，或维护一份独立的索引SET。这步漏掉，线上排查会多绕三圈。
