hash比string存对象更高效，核心在于按需加载和内存结构紧凑：hget/hmget可o(1)读单字段，避免json解析开销；小hash自动ziplist编码，省内存30%~50%，且字段名共享、无冗余序列化字符。
直接用 HGET 或 HMGET 查 Hash 字段，比把整个对象序列化成字符串存 SET 再反序列化快得多——前提是字段访问模式明确、不频繁全量读取。
为什么 Hash 比 String 存对象更高效？
核心不是“快”，而是「按需加载」和「内存结构紧凑」。String 存 JSON 后每次读都要解析整串；Hash 则在底层用 ziplist 或 hashtable 表示，单字段读写是 O(1)，且字段名和值独立编码，避免重复序列化开销。
- 小 Hash（默认 ≤512 字段，且每个 field/value ≤64 字节）自动用 ziplist 编码，内存占用比多个 String 键低 30%~50%
-
HGET user:100 name只触达 name 字段，不会加载 age、phone 等无关字段 - 字段缺失时
HGET返回(nil)，不报错也不中断，适合宽松 schema 场景
HMGET 批量查字段时要注意什么？
批量查多个字段用 HMGET 是对的，但容易忽略两点：字段顺序影响结果解析，以及缺失字段返回 nil 的处理逻辑。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 返回值严格按输入字段顺序排列，比如
HMGET user:100 name email avatar总是返回三元素列表，哪怕avatar不存在 - 客户端必须能容忍
nil，不能假设所有字段都存在（尤其跨版本或灰度发布时） - 字段数超过 10 个时，建议拆成两组调用——Redis 单命令参数过多会增加解析开销，实测 5~8 字段吞吐最优
哪些场景不该用 Hash？
Hash 不是万能对象容器，滥用反而拖慢查询。
- 需要模糊匹配字段名（如查所有以 “addr_” 开头的字段）——
HSCAN是 O(n) 扫描，不如用单独 key +SCAN做命名空间隔离 - 字段值极大（如存储 Base64 图片），导致单个 Hash 超过几 MB——Redis 对单个 value 有 512MB 上限，但大 value 会阻塞主线程，且 ziplist 编码失效后内存翻倍
- 频繁全量读取（
HGETALL）+ 高并发——该命令时间复杂度 O(N)，N 是字段数，字段超百后延迟明显上升，此时应考虑拆成主键 + 关联 key
真正关键的是字段访问粒度：如果 80% 的请求只读 2~3 个字段，Hash 就是最佳选择；如果每次都要 HGETALL 或遍历字段做计算，那得重新设计数据模型，而不是调优命令。
