Hash大field导致淘汰延迟，因HDEL/HDEL同步释放O(N)内存；应拆分为独立key并启用lazyfree-lazy-eviction等配置。
Hash 类型里单个 field 太大，HSET 和 HDEL 都会变慢，尤其是触发淘汰时卡顿明显——这不是 Redis 的 bug，是内存释放机制决定的。
为什么 Hash 的大 Field 会导致淘汰延迟
Redis 淘汰 key 时，如果 key 是 HASH 类型，且某个 field 的 value 占用几 MB 甚至更大（比如存了一段 base64 图片或 JSON 日志），那么 HDEL 或自动淘汰时释放该 field 内存的操作不是 O(1)，而是 O(N)，N 就是这个 value 的字节数。更关键的是：这个释放动作在主线程同步执行，期间无法处理其他请求。
- 现象：慢日志里频繁出现
HDEL或DEL耗时 >10ms，即使 key 只有一个 field - 原因：Redis 4.0+ 默认未开启
lazyfree-lazy-eviction，淘汰时同步释放；而HASH的 field 内存是堆内分配，释放需逐字节清理（尤其启用了 jemalloc 时） - 对比：小 key 淘汰耗时通常
如何确认 Hash 中存在大 Field
仅靠 redis-cli --bigkeys 不够——它只按 key 级别统计总大小，对 HASH 类型只会报告 “largest hash has N fields”，但不告诉你哪个 field 多大。
- 用
hscan+strlen手动抽样检查（生产慎用全量）：HSCAN myhash 0 COUNT 100
拿到 field 后，对可疑 field 执行STRLEN测大小 - 更稳妥方式：在业务写入侧加埋点，对
HSET的 value 长度做记录和告警（例如 >100KB 就打日志） - 用
redis-cli --memkeys（Redis 7.0+）可查看每个 field 的近似内存占用，但需提前开启memory doctor支持
切分小 Key 比改用 HASH 更可靠
很多人想“优化”成 HASH 是为了节省 key 数量，但若 field 本身就不该聚合，硬塞进 HASH 反而放大风险。直接拆成独立 key 更可控。
- 原结构：
HSET user:1001 profile "{...5MB JSON...}" - 改为：
SET user:1001:profile:basic "{'name':'a','age':30}"+SET user:1001:profile:detail "base64..." - 优势：淘汰单个 key 时只释放对应 value，无连锁影响；支持独立过期（
EXPIRE）；便于按需读取，避免网络传输冗余数据 - 注意：key 命名要带业务标识，避免不同模块 key 冲突；删除整组时用
SCAN+DEL批量，别用KEYS
淘汰策略与 lazyfree 配置必须配套调整
光拆 key 不够，如果实例仍启用 allkeys-lru 且没开 lazyfree，大 value 淘汰照样卡。
- 必须设置：
CONFIG SET lazyfree-lazy-eviction yes（淘汰时异步释放） - 同时建议：
CONFIG SET lazyfree-lazy-expire yes（过期 key 异步释放） - 避免用
volatile-lfu或allkeys-lfu：LFU 统计本身有额外开销，对高频写大 value 场景反而加重负担 - 如业务允许，可临时设为
allkeys-random：随机淘汰比 LRU/LFU 快得多，尤其适合写多读少、value 大小差异大的场景
真正难的不是发现大 Field，而是说服业务方接受“一个逻辑对象 = 多个物理 key”。很多延时问题最终卡在 schema 设计层——只要还在把日志、附件、富文本往 HASH 里塞，淘汰延迟就永远在等下一个 5MB 字段被删掉。
