Redis 8.10 Compact Hash 对内存型数据结构的影响

如果一批 Redis Hash 都表示同一种对象，字段名往往一遍遍重复出现。Redis 8.10 引入 Compact Hash，把相同字段集合提取成共享模板，每个键主要保存字段值和模板引用。这样可以减少重复元数据，但它不是“所有 Hash 自动变省内存”：字段经常变化、字段集合几乎不共享或单个 Hash 过宽时，收益可能很小。

官方资料：https://redis.io/docs/latest/develop/data-types/hashes/

迁移判断可以压缩成一句话：先确认大量键是否拥有稳定且相同的字段集合，再开启自动转换或选择 HIMPORT，最后用运行指标确认模板确实被复用。

Redis 8.10 改变了什么

传统 Hash 会在每个键中保存自己的字段名和值。以用户资料为例，name、email、age 会在很多键里重复。Compact Hash 将字段名集合登记为模板，各个键保存模板引用和按字段顺序排列的值；对外仍然使用 HGET、HSET、HGETALL 等 Hash 命令，调用语义不因内部编码改变。

这和 Redis 7 以后面向小 Hash 的 listpack 不是同一个概念：listpack 解决小对象的紧凑存储，Compact Hash 重点解决多个 Hash 共享字段名。不要只看到版本升级就假设已有数据会立刻重写；转换有明确的触发路径和生效时机。

升级时先看数据形态，再决定参数

最适合评估的是“很多键、同一组字段、字段长期稳定”的对象映射，例如用户资料、设备快照或订单摘要。字段名越稳定、共享键数量越多，模板的固定成本越容易被摊薄。相反，按请求临时拼接字段、每个键字段都不同、持续 HSET 新字段或频繁 HDEL 的数据，不应直接套用 Compact Hash。

还要谨慎处理超宽 Hash 和字段过期。字段集合频繁变化会触发重新解析，宽 Hash 在复制或槽位迁移时也可能放大单个对象的传输压力；使用字段过期的 Hash 不会转换为 Compact Hash。迁移前应先按业务对象分组，而不是按全库平均内存做结论。

配置参数什么时候生效

自动转换默认关闭，可在灰度实例上设置字段数量范围。下面的配置只表达策略，具体阈值需要结合对象大小与写入模式压测：

# 只让字段数量落在业务对象范围内的 Hash 尝试转换
CONFIG SET hash-min-template-entries 3
CONFIG SET hash-max-template-entries 12

# 旧 RDB 加载时尝试把符合条件的普通 Hash 转成模板
CONFIG SET hash-rdb-load-min-template-entries 3
CONFIG SET hash-rdb-load-max-template-entries 12
# 共享键数量太少时拆回普通 Hash，避免模板元数据反而浪费内存
CONFIG SET hash-rdb-load-template-disassembly-threshold 100

写入路径的配置是惰性的：修改 CONFIG SET 后，已有键不会瞬间全部改写，相关 Hash 要等下一次写入才有机会转换。RDB 加载参数则服务于升级或恢复场景，是否能形成共享模板取决于加载出来的字段集合；阈值过高可能让低复用模板被拆回普通 Hash。

如果业务可以控制批量导入，Redis 8.10 的 HIMPORT 可以先准备一次字段集合，再批量写入多个 Hash，减少重复发送字段名和逐条命令的成本。它适合有明确 schema 的导入链路；普通应用则可以先从自动转换开始，避免一次改造客户端协议。

用指标确认内存收益

迁移不能只看“配置已写入”。应把升级前后的同类对象、键数量和访问负载放在相近时间窗口比较：

# 查看 Compact Hash 模板数量与使用模板的键数量
INFO STATS

# 查看模板本身消耗的内存，以及其他内存分项
INFO MEMORY
MEMORY STATS

# 抽样比较单个键的实际占用
MEMORY USAGE user:10001 SAMPLES 0
# 抽样键只用于对比，不要把一个键的结果外推到整个实例

重点观察 hash_templates、hash_template_keys 和 used_memory_hash_templates。MEMORY USAGE 会把键自身内存和共享模板分摊成本纳入观察，因此应配合一批同 schema 键的样本判断。若模板数量持续增长而模板键数量很少，说明字段集合过于分散；若写入延迟、复制流量或迁移耗时上升，则要回到对象宽度和字段变更频率重新评估。

一份可执行的升级清单

1. 按对象类型统计字段集合的重复度、字段数量和字段变更频率，先找出稳定 schema。
2. 在非生产或灰度节点设置较窄的最小/最大字段数量，记录基线内存和写入延迟。
3. 优先让一小组新写入键转换；对 RDB 恢复路径单独评估加载时间、模板复用和拆解阈值。
4. 持续观察模板指标、抽样键内存、复制/槽位迁移和慢命令，发现收益不明显就回退自动转换参数。

结论是：Compact Hash 更像“稳定对象集合的内存布局优化”，不是通用的 Hash 加速开关。把字段稳定性、共享规模和迁移路径一起纳入决策，才不会为了追求更小的内存占用而引入难以解释的写入成本。

相关问题

Compact Hash 会改变 HGETALL 返回结果吗？不会，内部编码变化不应改变 Hash 命令的外部语义；但仍需按业务样本观察内存、复制和迁移成本。

为什么设置了最小字段数却没有马上看到变化？自动转换按后续写入惰性生效，已有键不会因 CONFIG SET 立即全部改写；RDB 加载参数只在相应加载路径发挥作用。

字段名经常变化的 session Hash 适合吗？通常要谨慎。频繁新增、删除字段会削弱模板复用，且字段过期场景不会转换，应先用真实负载做对比。