Hash结构不适合直接存整个JSON字符串，因会浪费字段级操作能力并引入额外解析开销；正确做法是将JSON顶层字段拆解为独立field-value对，避免嵌套与长值导致ziplist退化。
Hash结构不适合直接存整个JSON字符串
很多人误用 HSET 把一整段 JSON 当作单个 value 存进 Hash，比如：HSET user:1001 data '{"name":"Alice","age":30}'。这完全浪费了 Hash 的字段级能力，还引入额外解析开销——读取时仍要反序列化整个字符串，更新时也得重写全部字段。
真正高效的做法是把 JSON 的顶层字段拆出来，一对一映射到 Hash 的 field-value 上：
HSET user:1001 name "Alice" age 30 city "Beijing"- 避免嵌套：如果原始 JSON 有
{"profile": {"bio": "xxx", "tags": [...]}}，不要硬塞进一个 field；要么扁平化（profile_bio,profile_tags），要么改用其他方案 - 字段名保持简洁、无特殊字符（如空格、点号），否则部分客户端解析可能出错
Hash 存 JSON 的内存和性能优势在哪
Hash 在满足 hash-max-ziplist-entries ≤ 512 且所有 field/value 长度 ≤ hash-max-ziplist-value（默认 64 字节）时，底层用 ziplist 编码，比 String 存整个 JSON 节省约 20%～50% 内存。
但注意这个优势会快速消失：
Json Schema Toolkit
下载
使用 JSON Schema 验证 JSON 数据，从示例 JSON 生成 schema，并将其转换为 TypeScript 接口、Python 数据类或 Markdown 文档。
- 一旦某个 value（比如用户 bio）超过 64 字节，整个 Hash 会从 ziplist 升级为 hashtable，内存占用跳变式上升
- 字段数超 512 个，同样触发升级，且 hashtable 的指针开销明显增大
- 实测：10 万个 key，每个含 5 个短字段（
什么时候该放弃 Hash，改用 RedisJSON 或 String
当你的 JSON 有以下任一特征，Hash 就不是最优解：
- 存在深层嵌套（如
{"order": {"items": [{"id":1,"qty":2}, ...]}}），Hash 无法自然表达层级 - 需要频繁按路径查询或局部修改（如只更新
$.order.items[0].qty），Hash 没有原生支持 - 字段值长度差异极大（有的 nickname 是 "A"，有的 bio 是 5000 字符），极易触发 hashtable 升级
- 业务要求 TTL 粒度精确到单个对象（Hash 本身不支持 key 级 TTL，只能靠
EXPIRE整个 Hash）
这时更合适的选择是：RedisJSON（支持 JSON.GET/JSON.SET 和 JSONPath）、或退回到 String + json.dumps/json.loads（适合读多写少、整对象操作场景）。
Hash 存 JSON 必须调的两个配置项
生产环境不调整默认值，Hash 很容易“悄无声息地变胖”。关键配置在 redis.conf 中：
-
hash-max-ziplist-entries：建议根据实际字段数设为 128 或 256（而非默认 512），避免小对象意外升级 -
hash-max-ziplist-value：若业务中常见中等长度字段（如 email、description），可提到 128 或 256，但别超过 1024 —— 否则 ziplist 失去紧凑优势 - 改完必须重启 Redis 或用
CONFIG SET生效，且仅影响新建 Hash；已有数据编码方式不会自动降级
最易被忽略的是：这些参数对已存在的 Hash 无效，上线新配置后，旧数据仍维持原编码，只有新写入的才按新规则走。
