HSET 更适合缓存结构扁平、字段更新频繁的对象，如用户信息；因其节省CPU/IO、支持原子操作、内存更优（ziplist编码），但不适用于需整对象TTL、深层嵌套或字段极少场景。
什么时候该用 HSET 而不是 SET
你正在缓存一个用户信息，比如 uid、name、age、city 四个字段，且业务中经常只改其中一两个（例如用户改昵称），这时用 HSET user:1001 name "Bob" 就比 SET user:1001 '{"uid":1001,"name":"Bob","age":30,"city":"上海"}' 更合理。因为：
- 不用读取整个 JSON 再反序列化、改字段、再序列化、再写回 —— 节省 CPU 和网络 IO
- 单次操作只传输字段名和新值，比如
name和"Bob"，而不是几百字节的完整 JSON - 如果某字段是计数器（如登录次数），可直接用
HINCRBY user:1001 login_count 1原子递增，String 做不到
HSET 的内存优势从哪来
Redis 对小 Hash（默认 ≤512 字段，每个 value ≤64 字节）会启用 ziplist 编码，把所有字段紧凑存进一块连续内存里，只消耗 1 个 redisObject 头（16 字节）+ 1 个 SDS 头（8 字节）。而用 String 存四个字段，就得建 4 个 key，每个都带独立的 redisObject + SDS 开销 —— 光对象头就多花 48 字节，还不算 key 名重复存储的冗余。
实测：存 1000 个用户（各 4 字段），Hash 比 JSON String 省约 30%~40% 内存，尤其字段值短时更明显。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
别踩这些坑：Hash 不是万能的
以下情况反而该用 String：
- 需要给整个对象设过期时间 ——
EXPIRE user:1001 3600直接生效；Hash 无法对整个结构设 TTL，只能靠EXPIRE作用于 key，但字段级操作（如HSET）不会重置 TTL - 对象有深层嵌套（如
address.province）—— Hash 只支持一级 field，得展平成address_province，维护成本高 - 跨语言客户端不统一支持 Hash 命令（极少见，但某些旧版 PHP 或嵌入式 SDK 可能弱化 Hash 支持）
- 字段极少（仅 1~2 个）、且几乎不单独更新 —— 此时 String 的简单性胜过 Hash 的结构开销
混合用法其实更常见
真实业务里，纯 String 或纯 Hash 往往都不是最优解。例如：
- 把高频更新、需原子操作的字段（
login_count、last_login_time）放进 Hash - 把大文本字段（
bio、avatar_url）单独用 String 存，避免拖慢 Hash 的 ziplist 编码或触发转 HT - 用
user:1001:profile（Hash） +user:1001:bio（String）组合，兼顾灵活性与 TTL 控制
真正容易被忽略的是：Hash 的内存优势依赖于实际数据规模和配置。如果字段太多或 value 太大（比如存了 base64 图片），Redis 会自动从 ziplist 升级为哈希表（HT），内存开销会上升，此时得结合 INFO memory 和 MEMORY USAGE 实测验证，不能只看理论。
