String适合单值高频读写，字段更新需全量覆盖；Hash支持字段级原子操作但小字段多时内存放大。
String 适合单值高频读写，但字段级更新必须全量覆盖
当业务场景里一个实体只存一个值（比如用户 token、配置开关、计数器），SET 和 GET 就是最快最省的。Redis 对 String 的操作是原子且 O(1) 的，内存也最紧凑。
但一旦你把它当“对象”用——比如存 JSON 字符串 {"name":"alice","age":28,"city":"sh"}，问题就来了：每次改 age，你得先 GET 全量，反序列化，改字段，再序列化，最后 SET 回去。网络 + CPU + 序列化开销全摊在一次字段更新上。
常见错误现象：
- 接口响应时间忽高忽低，尤其在大 JSON（>2KB）时更明显
- 并发写入时出现字段覆盖（A 读→改 name→写，B 读→改 age→写，B 的写把 A 的 name 改动冲掉了）
实操建议：
- ✅ 单值缓存（session id、临时验证码、开关标志）用 String
- ❌ 不要用 String 存多字段对象，除非该对象完全只读或极少更新
- ⚠️ 如果已用 String 存了 JSON，又需要局部更新，别硬扛，该切就切
Hash 天然支持字段粒度操作，但小字段多时有内存放大
HGET、HSET、HINCRBY 这些命令直接对 field 级别生效，不碰其他字段。适合用户资料、商品属性、配置项分组这类“一个 key 对应多个可独立读写的字段”的场景。
但 Hash 不是银弹。Redis 内部对小 Hash（字段数 ≤ 512，单 field/value 长度 ≤ 64 字节）会用 ziplist 编码，省内存；超过阈值自动转成 hashtable，内存占用可能翻倍。你存 100 个空字符串字段，实际内存可能比 100 个独立 String key 还高。
使用场景判断点：
- 字段是否经常单独读/写？比如“查用户城市”、“给积分+1”、“更新最后登录时间”
- 字段总数是否稳定？是否会长期增长到几百个？
- 是否需要原子性地批量更新几个字段（HMSET 或 HSET key f1 v1 f2 v2）？
实操建议：
- ✅ 字段数适中（Hash
- ❌ 字段极多（如日志 tag 映射表，上千 field）或单 field 超大（如存 base64 图片）→ 改用独立 String key 或其他结构
- ⚠️ 生产环境上线前，用 MEMORY USAGE key 对比下同数据量下 String JSON 和 Hash 的实际内存差
字段读写频率差异大时，混合结构比硬选一种更靠谱
真实业务里，一个用户对象常有“高频字段”（last_login_time、status）和“低频字段”（bio、avatar_url）。全塞 Hash 会导致低频字段拖慢整体编码效率；全拆 String 又丧失关联性、增加 key 数量和运维成本。
更务实的做法是分层存储：
- 高频字段走独立 String key（如 user:1001:status、user:1001:score），享受极致性能
- 中低频字段合并在一个 Hash（如 user:1001:profile），用 HGETALL 批量拉取，减少往返
- 极冷字段（如历史操作记录）甚至扔到 MySQL 或冷存服务，Redis 只留指针
容易踩的坑：
- 混合结构后没统一过期策略：String key 设了 1h 过期，Hash key 忘设，导致数据不一致
- 字段归属模糊：updated_at 到底放高频 key 还是 profile hash？团队得约定清楚，否则后续难维护
实操建议：
- ✅ 用命名规范区分层级，比如 user:{id}:status（高频）、user:{id}:profile（中频）、user:{id}:meta（低频）
- ✅ 所有相关 key 统一用 EXPIRE 或从源头设置 TTL，别依赖业务代码手动清理
- ⚠️ 别为了“理论最优”强行拆太细——加 3 个 key 带来的运维复杂度，有时比多占 2KB 内存更伤
用 OBJECT ENCODING 和 MEMORY USAGE 定量验证你的选择
光靠文档描述猜编码方式或内存表现，很容易翻车。Redis 提供两个命令能直接告诉你“它现在到底怎么存的”：
OBJECT ENCODING key 返回当前底层编码（int、embstr、hashtable、ziplist 等），帮你确认 Hash 是否还处于省内存的 ziplist 模式；MEMORY USAGE key 返回该 key 实际占用字节数，是横向对比 String vs Hash 的唯一可靠依据。
实操建议：
- ✅ 上线前必跑：插入典型数据量（比如 50 个字段，每个 value 32 字节），执行 OBJECT ENCODING 和 MEMORY USAGE
- ✅ 对比时注意 client 缓存和序列化开销——如果应用层 JSON 解析本身就很重，那 Redis 层面省下的那点内存可能意义不大
- ⚠️ MEMORY USAGE 不包含 key 名本身长度，但长 key 名在大量 key 场景下也会吃内存，别忽略
复杂点往往不在选 String 还是 Hash，而在于你有没有在真实数据规模下测过它们的内存拐点和访问延迟。没测过的“最优选择”，大概率是拍脑袋决定的。
