Redis 8.10 Compact Hash 怎么省字段名内存：共享 schema 的适用条件

一批用户资料都只有 name、email、level 三个字段时，普通 Hash 会在每个键里重复保存这些字段名。Redis 8.10 的 Compact Hash 针对的正是这类重复：结构一致的多个 Hash 可以共用一份字段模板，各自只保留值。它能省多少不能只看单个键，关键在于键的数量、字段名长度和 schema 是否长期稳定。

Compact Hash 真正共享的是什么

可以把 user:1001 与 user:1002 想成两行数据：它们的值不同，但字段都是 name、email、level。Redis 8.10 为这类键准备“字段模板”，让多个 Hash 实例引用同一份字段集合。官方 8.10 更新说明的原话边界很清楚：字段名只为共享 schema 的键保存一次。

HSET user:1001 name "Lin" email "lin@example.test" level "gold"
HSET user:1002 name "Ming" email "ming@example.test" level "silver"

上面只是展示逻辑结构，不代表写完两条命令就一定获得相同的节省比例。真正的收益来自“很多键 × 重复字段名”；如果只有两个小 Hash，模板本身也有成本，观察到的差异可能很小。

哪些数据更适合共享 schema

最合适的是大批结构统一的对象，例如会话摘要、玩家积分、商品简档或设备状态快照。判断时先看四件事：

这里别把 Compact Hash 和 HIMPORT 混成一件事。Compact Hash 是存储编码，HIMPORT 是 Redis 8.10 提供的批量导入命令，它通过预先声明 fieldset，减少批量传输时反复发送字段名。两者都利用“字段集合稳定”这个条件，但一个解决内存重复，一个还关注网络与批量写入。连接池里的 HIMPORT fieldset 需要逐连接准备，这属于导入会话边界，不等于服务器中的字段模板只属于某条连接。

怎么确认 compact hash 真的被采用

Redis 8.10 增加了专门的可观测指标。先在 INFO STATS 查看 hash_templates 与 hash_template_keys：前者是不同模板数量，后者是由模板支撑的键总数。模板很少、键很多，通常更符合高复用的预期。

再看内存：INFO MEMORY 的 used_memory_hash_templates 与 MEMORY STATS 的 hash.templates 都用于观察模板总成本。最后用 MEMORY USAGE 抽查单键；官方说明它报告键自身内存，并加上该键分摊的共享模板成本。这样比较才不会把模板成本误认为“凭空消失”。

验证时最好对照一组真实数据：先记录键数、字段集合与总内存，再导入结构一致的样本，观察模板数量、模板键数量和总内存的变化。不要引用别人的固定节省百分比；字段长度、值大小和键规模不同，比例自然不同。

配置边界与采用建议

Redis 8.10 还提供三项载入期配置：hash-rdb-load-min-template-entries 与 hash-rdb-load-max-template-entries 控制普通 Hash 在载入时转为模板的字段数范围，hash-rdb-load-template-disassembly-threshold 则用于判断转换后的模板至少要支撑多少键才保留。调整前先用默认值跑一份接近生产分布的数据，再结合模板键数和模板内存判断。

采用顺序可以很保守：先找字段集合稳定、键量最大的业务族；把可选字段拆到另一类 Hash，减少主 schema 分叉；升级后以指标验收，而不是仅看命令返回成功。若业务对象天然稀疏、字段不断变化，普通 Hash 的灵活性往往更重要。

常见问题

字段值很大时，Compact Hash 仍然明显省内存吗？

它主要消除重复字段名。值越大，字段名占总内存的比例通常越低，所以相对节省可能变小；仍应以真实样本和模板指标核对。

用了 HIMPORT 就一定会得到 Compact Hash 吗？

不要这样等同。HIMPORT 通过 fieldset 优化批量导入，Compact Hash 关注共享字段模板的存储收益。两者适用条件相近，但验收时仍要查看模板数量、模板键数和内存指标。