Redis中HSET子键数量阈值及分片后空间优化疑问

嘿，我来帮你把这个问题掰明白～

首先得明确Redis哈希的两种核心编码模式：

• ziplist（压缩列表）：这是Redis为节省内存专门设计的紧凑存储格式，当哈希满足配置阈值时会启用它，空间利用率极高。
• hashtable（普通哈希表）：当哈希规模超出阈值后，Redis会自动切换到这种模式，读写性能稳定，但内存占用会比ziplist高不少。

回到你的配置：

redis-store:6379> config get hash-*
1) "hash-max-ziplist-entries"
2) "512"
3) "hash-max-ziplist-value"
4) "64"

这里的hash-max-ziplist-entries=512是关键阈值——当某个哈希的子键数量超过512时，Redis就会把这个哈希的编码从ziplist切换成hashtable，此时就没法享受ziplist的空间优化了。

你的分片方案是按前两位字符拆分，每个哈希有10000个子键，这个数量远大于512，所以这些哈希肯定会被转换成hashtable编码，确实失去了空间优化的优势。

调整建议 #

如果想继续利用ziplist的紧凑存储，你需要调整分片策略，让每个哈希的子键数控制在512以内：

• 比如改成按前四位字符分片：100万条数据会分成10000个哈希，每个哈希刚好有100个子键，完全在512的阈值内，能保持ziplist编码。
• 要是按前三位分片，每个哈希会有1000个子键，还是超过512，依然会触发编码转换。

另外，你可以用OBJECT ENCODING your_hash_key命令查看某个哈希的实际编码，直观确认它是否处于ziplist模式。

如果你的核心需求只是减少顶层键的数量，而非极致内存优化，当前的100个哈希方案也能正常工作，只是内存占用会比ziplist模式高一些，这需要你根据自身内存资源权衡。

内容的提问来源于stack exchange，提问作者Peter Bengtsson