Redis Hash 单 key 理论上限为 2^32−1 个键值对，但实际受限于内存、性能及编码切换机制；默认配置下超 512 个 field 或任一 value 超 64 字节即升为 hashtable，且不可降级；大 Hash 应按业务分片而非硬扛。
2^32 - 1（即 4294967295）是 Redis Hash 类型单个 key 理论上能存的最大键值对数量。但这只是理论上限，实际根本达不到——内存、性能和编码切换机制会提前把你拦住。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
hash-max-ziplist-entries 和 hash-max-ziplist-value 决定底层编码
Redis 不会一直用哈希表存所有 Hash；它会在满足条件时用更省内存的ziplist（压缩列表），否则自动切到 hashtable。这个切换由两个配置控制：
-
hash-max-ziplist-entries：默认512，指 field 总数不能超过该值（含等于） -
hash-max-ziplist-value：默认64，指每个 field 或 value 的字符串长度都不能超过该字节数
ziplist；任一不满足，整个 Hash 就升为 hashtable 编码。一旦升级，**不会降级回 ziplist**，哪怕你后续删掉大部分 field。
超过 512 个 field 后性能变化明显
ziplist 是连续内存块，查找是 O(n)，但小数据下快且省空间；hashtable 平均 O(1)，但有哈希冲突、指针开销、内存碎片问题。实测中：
- field 数从 500 增到 1000，
HGET延迟可能翻倍（尤其在高并发场景） - 单个 Hash 存 10 万 field 时，RDB 快照时间显著增长，AOF rewrite 更容易触发阻塞
- 内存占用不是线性增长：每个 field 在 hashtable 下额外多占约 32–64 字节元数据（取决于架构）
4294967295 看，真存到百万级 field，你最先遇到的是运维报警，不是 Redis 报错。
大 Hash 拆分比硬扛更实际
想存大量属性或用户维度数据？直接堆到一个 Hash 里是反模式。推荐按业务逻辑分片：- 按 ID 取模：
user:profile:{user_id % 100}，把 1 亿用户打散到 100 个 key - 按时间分桶：
log:202607:hour14，避免单 key 持续膨胀 - 字段归类拆解：
user:basic:{id}存 name/age，user:setting:{id}存偏好，互不影响 TTL 和更新频率
HGETALL 不再可用，得用 pipeline 或客户端聚合 —— 这不是缺陷，而是为可扩展性付出的合理代价。
真正卡住你的从来不是 2^32 - 1 这个数字，而是当 Hash 超过几万 field 时，你才发现 HKEYS 返回结果太大拖垮网络，或者 HDEL 删除一批 field 居然要几百毫秒 —— 这些问题不会报错，但会让监控曲线突然变陡。
