String类型在LRU驱逐场景下内存效率低，因其每个key和value均独立占用redisObject+SDS结构，导致对象头冗余高、驱逐粒度粗；而Hash等结构共享key对象头、支持ziplist压缩，内存利用率高40%~60%。
String 类型在 LRU 驱逐场景下内存效率低，不是因为不能用，而是它单 key 占用的内存开销远高于 Hash、ZSet 等结构——尤其当你要存大量小对象时。
为什么 String 的每个 key 都带“双重对象头”
Redis 中每个 key 对应一个 redisObject，而每个 value 也是一个 redisObject。String 类型的 value 若是短字符串（比如 "123" 或 "true"），Redis 会用 OBJ_ENCODING_EMBSTR 编码，但这个编码仍需独立分配一个 redisObject + 底层 SDS 结构；更关键的是：key 本身也必须是一个完整的 redisObject + SDS。
也就是说，存一个 user:1001:status → "active"，你实际占用了：
- 1 个 key 的
redisObject（16 字节） + SDS（至少 3 字节 len + 1 字节 \0 + 冗余空间） - 1 个 value 的
redisObject（16 字节） + SDS（同上）
而同样信息，如果用 Hash 存：HSET user:1001 status "active" email "a@b.com" role "user"，key 只算 1 次对象头，所有字段共用同一个 redisObject（底层是哈希表或 ziplist），字段名和值都作为 entry 存在内部结构里，没有额外的 key 对象开销。
LRU 驱逐时 String 的“粒度太粗”
LRU 淘汰是以 key 为单位的。String 类型天然是一对一映射，意味着：
- 你无法只淘汰某个用户的状态字段，只能整条
user:1001:statuskey 被踢走 - 如果业务上需要按访问热度分别管理字段（比如
email访问少、role访问多），String 完全无法支持 - 大量细粒度 key 会显著增加 Redis 哈希表桶数量和 rehash 开销，间接拖慢 LRU 采样性能
相比之下，Hash 的整个 user:1001 是一个 key，LRU 淘汰时要么全留、要么全走，但你可以靠业务逻辑控制“哪些用户值得保留”，而不是被几十个 :status :profile :settings key 把内存撑爆又无法精准干预。
什么情况下 String 还能接受？
String 不是绝对禁用，它在以下场景仍有合理位置：
- 单值强语义场景：如计数器
article:123:read_count（用INCR）、开关标志feature:abtest:v2:enabled（用GET/SET） - 大块二进制数据：如序列化后的用户详情 JSON（
512KB级别），此时对象头占比极小，SDS 冗余可控，且不适宜拆进 Hash（字段动态性低、无频繁部分更新） - 需要原子操作的场景：如
SETEX设置带过期的令牌，或GETRANGE做流式读取，这些是 Hash / ZSet 不直接支持的
但注意：SETEX user:1001:token "xxx" 3600 和 HSET user:1001 token "xxx" expire_ts "1744603320" 表面相似，后者却丧失了原生过期能力——你得自己用 EXPIRE 或定时任务清理，反而增加复杂度。
真正省内存的替代方案：Hash + ziplist 自动压缩
当单个 Hash 的 field 数量 ≤ hash-max-ziplist-entries（默认 512）且每个 field/value 长度 ≤ hash-max-ziplist-value（默认 64 字节）时，Redis 会自动用 ziplist 编码替代哈希表。
ziplist 是连续内存块，没有指针、没有哈希桶、没有单独的 redisObject 包裹每个 field——它把所有字段扁平化存储，仅靠长度前缀分隔，内存利用率比一堆 String 高 40%~60%。
实操建议：
- 确认配置：
CONFIG GET hash-max-ziplist-entries和CONFIG GET hash-max-ziplist-value - 批量写入优先用
HMSET（或HSET key f1 v1 f2 v2），避免多次HSET触发提前升级为 hashtable - 用
OBJECT ENCODING user:1001检查是否真走 ziplist；若返回"ziplist"，说明压缩生效
这比手动拼接字符串或改用其他序列化格式更轻量、更可靠——Redis 自己管压缩与升级，你只管按业务建模。
真正容易被忽略的点在于：**内存压力往往不是来自 value 大小，而是 key 的数量级和对象封装层数。String 的简洁性，在高密度缓存场景下反而成了内存杀手。**
