redis hash扩容期间cpu和内存明显上涨，因渐进式迁移需持续哈希重计算、指针更新与内存拷贝，且ht[0]和ht[1]共存致内存短暂翻倍；负载因子超1触发扩容（bgs save等场景放宽至5），目标大小为ht[0].used×2并向上取整为2的幂次方，易引发内存碎片与客户端延迟上升。
Redis Hash扩容期间CPU和内存会明显上涨
扩容不是瞬间完成的，而是渐进式迁移，但这个过程本身就会持续占用CPU做哈希重计算、指针更新和内存拷贝。同时，ht[0]和ht[1]两个哈希表共存，内存占用会短暂翻倍——哪怕只是临时的。
常见错误现象包括：INFO memory显示used_memory_peak_human突然跳升；redis-cli --stat观察到instantaneous_ops_per_sec波动剧烈；监控里看到rehashing指标非-1（即rehashidx >= 0）。
- 负载因子超过1触发扩容，但若正在执行
BGS SAVE或BGREWRITEAOF，阈值会放宽到5，此时更容易撞上高内存压力 - 扩容目标大小是
d->ht[0].used * 2，且必须是2的幂次方，所以实际分配可能比“刚好够用”更大 - 内存碎片风险升高：新旧表内存不连续，释放
ht[0]后未必能被OS立即回收，尤其在小内存机器上更敏感
客户端请求延迟变长，尤其是写操作
每次HSET、HDEL或HGET执行时，Redis都会顺带迁移一个桶（bucket）的数据。这意味着单次命令耗时变长，特别是当访问的是尚未迁移的旧表数据时，要查ht[0]和ht[1]两处——读写路径变复杂了。
使用场景中容易踩坑的是批量写入：比如用HMSET或管道（pipeline）塞入大量Hash字段，每个命令都触发一次迁移逻辑，叠加起来延迟明显。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 迁移粒度固定为“一个桶”，但桶内节点数不确定——如果某个桶链表很长（哈希冲突严重），单次迁移开销就大
-
rehashidx推进速度取决于操作频次，低流量时段可能拖很久才完成，导致性能波动持续时间不可控 - 缩容（负载因子
并发连接数突增可能加剧rehash抖动
rehash本身不阻塞主线程，但所有客户端命令都要参与迁移任务。当并发请求数陡增（比如秒杀开场），单位时间内触发的迁移次数剧增，CPU争抢更激烈，used_cpu_sys和used_cpu_user会同步飙升。
这不是bug，是设计使然：Redis把rehash“摊”进日常操作，所以越忙越容易抖。你看到的延迟毛刺，往往不是网络或IO问题，而是rehash在后台悄悄干活。
- 没有“暂停rehash”的安全开关，
pauserehash字段仅用于持久化期间内部协调，不可手动干预 - 监控关键指标应包含
rehashing（是否正在进行）、ht0_used/ht1_used（两表实时数据量）、以及instantaneous_input_kbps（流量突增是否同步触发抖动） - 大Hash对象建议预估容量，用
HCREATE类命令（如果客户端支持）提前分配空间，避免运行时频繁扩容
旧key长期不访问会导致rehash卡住
渐进式rehash依赖“有操作才迁移”。如果某个Hash里有大量key，但其中一部分长期无人访问（比如冷数据字段），那对应的桶就永远不会被迁移——rehashidx停在那里，ht[0]无法彻底释放，内存一直挂着。
这在配置类、日志类Hash中很常见：写一次，读零次，却始终占着双表内存。
- 没有后台线程兜底迁移，全靠用户请求驱动，这是最易被忽略的设计约束
-
redis-cli --bigkeys只能发现大key，无法识别“半迁移”状态；需用DEBUG HTSTATS <key></key>（仅开发/测试环境）确认迁移进度 - 真正解决办法不是等它自己动，而是主动触发访问——比如用
HEXISTS轮询冷字段，或定期HGETALL强制推进，但要注意别引发新的性能雪崩
