哈希字段过多时，Redis会从ziplist升级为hashtable编码导致内存激增；应调低hash-max-ziplist参数、用HSCAN替代HGETALL、按访问模式决定是否拆分为string key，并避免线上CONFIG SET引发阻塞。
哈希字段太多时，HSET 会悄悄吃掉大量内存
Redis 的哈希（hash）结构在字段数少、值小的时候很省空间，用的是 ziplist 编码；但一旦字段数超过 hash-max-ziplist-entries（默认 512）或任意字段值长度超过 hash-max-ziplist-value（默认 64 字节），就会升级成 hashtable 编码——内存占用直接翻几倍，还失去紧凑性。
常见错误现象：MEMORY USAGE 查一个只有 200 个字段的 hash，结果占了 20KB+；或者用 INFO memory 发现 used_memory_human 涨得快，但 dbX 的 key 数没变多。
- 检查当前编码：
OBJECT ENCODING your_hash_key，返回hashtable就已“膨胀” - 调低
hash-max-ziplist-entries和hash-max-ziplist-value（比如设为 128 / 32），让更小的 hash 继续走ziplist - 注意：不能无限制压低，否则频繁 rehash 反而增加 CPU 开销；建议先用
redis-cli --bigkeys找出真正“胖”的 hash 再针对性处理
用 HSCAN 替代 HGETALL 避免单次加载全量字段
HGETALL 把整个 hash 拷贝到客户端内存里，字段一多（比如上千个），不仅服务端序列化压力大，客户端也容易 OOM。这不是内存“存储”问题，而是“使用方式”引发的瞬时内存峰值。
典型场景：后台任务遍历用户属性 hash 做聚合，写成 HGETALL user:123 + for 循环处理，结果 Redis 实例 RSS 突增，慢日志里全是 HGETALL 超时。
- 改用
HSCAN user:123 MATCH * COUNT 50分批拉取，每次只处理几十个字段 -
COUNT不是硬限制，只是提示，实际返回可能略多；别设太大（如 1000+），否则仍可能卡住连接 - 如果业务允许最终一致性，可考虑把 hash 拆成多个小 hash（如
user:123:profile、user:123:settings），天然限宽
字符串替代哈希？看访问模式再决定
不是所有“多个字段”都该用 hash。如果字段之间从不一起读写，比如 user:123:name、user:123:email 各自独立更新，那用独立 string key 反而更省内存——没有 hash 的元数据开销（dictEntry、sds header 等），还能按需过期、迁移。
性能影响明显：10 万个用户，每个用 1 个 hash 存 5 个字段 vs 拆成 5 个 string key，前者内存高约 18%（实测 6.2MB → 7.3MB），且 EXPIRE 必须整 hash 设，没法单独过期邮箱。
- 适合保留 hash 的情况：
HMGET/HMSET高频、字段强关联（如商品 SKU 的price/stock/status）、需要原子性批量操作 - 适合拆成 string 的情况：字段生命周期不同（头像 URL 过期快，注册时间永不过期）、读写粒度极细（前端只查 name，从不碰 email）、key 总数可控（避免 key 数爆炸）
- 别为了“结构清晰”硬套 hash——Redis 不是 MySQL，没有 schema 约束，存得散点没关系
CONFIG SET 动态调参有风险，上线前必须压测
改 hash-max-ziplist-entries 看似立竿见影，但线上直接 CONFIG SET 可能触发批量 rehash：Redis 会逐个检查现有 hash，符合条件的立刻转编码，期间阻塞主线程，QPS 断崖下跌。
错误做法：运维在凌晨发一条 CONFIG SET hash-max-ziplist-entries 64，然后去睡觉，早上发现监控里有 3 秒以上的 command 延迟 spike。
- 新实例直接配
redis.conf，避免运行时变更 - 老实例要调参，先用
DEBUG OBJECT key抽样看目标 hash 的当前编码和字段分布，估算 rehash 量级 - 如果已有大量
hashtablehash，不如新建一批小 hash，逐步迁移，比硬切配置更稳
最常被忽略的一点：内存节省是有代价的——ziplist 查询是 O(N)，字段越多越慢；别为了省几百 KB 内存，把热点 hash 的平均延迟从 0.1ms 拉到 0.8ms。
