Redis 7.2 升级后淘汰变慢主因是 lazyfree-lazy-eviction 默认未开启及 maxmemory-samples 从5升至10导致扫描开销增大，需手动启用懒释放并调回采样值以降低延迟。
Redis 5.0 升级到 7.2 后内存淘汰变慢，不是版本升级“自动优化”了就能高枕无忧——恰恰相反，allkeys-lru 或 volatile-lru 这类淘汰策略在 7.2 中默认行为未变，但底层淘汰逻辑、内存管理机制和 lazyfree 控制粒度有实质性调整，容易导致淘汰耗时上升、延迟毛刺增多。
确认淘汰是否真成瓶颈：看 evicted_keys 和 expired_keys 增速是否匹配写入压力
先别急着调参数。用 INFO stats 查两个关键指标：
-
evicted_keys：被主动淘汰的 key 总数，持续增长说明确实在频繁触发淘汰 -
expired_keys：过期 key 删除总数，若它远高于evicted_keys，说明主线程正被集中过期拖累，而非淘汰策略本身问题 - 对比写入 OPS（
instantaneous_ops_per_sec）：如果每秒写入 5k，但evicted_keys每秒只增 100，说明淘汰没跟上节奏，积压会抬高延迟
再配合 INFO memory 看 mem_fragmentation_ratio 是否 > 1.5 —— 高碎片会让 lazyfree 实际释放变慢，即使开了也效果打折。
检查 lazyfree 配置是否真正生效
Redis 7.2 默认仍关闭部分 lazyfree 场景，尤其 lazyfree-lazy-eviction 是手动开启项，不配置就退回到 5.0 的同步淘汰模式。
- 运行
CONFIG GET lazyfree-lazy-eviction，返回"no"就是没开 —— 这是最常见漏配点 - 7.2 新增
lazyfree-lazy-server-del（影响FLUSHDB/FLUSHALL）和lazyfree-lazy-user-del（影响UNLINK），但它们不影响日常写入触发的淘汰 - 必须同时设
lazyfree-lazy-eviction yes+maxmemory-policy为支持 lazyfree 的策略（allkeys-lru等都支持，但noeviction不适用）
改完记得 CONFIG REWRITE 持久化，否则重启失效。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
警惕 7.2 的 maxmemory-samples 默认值变化与淘汰效率陷阱
Redis 7.2 把 maxmemory-samples 默认值从 5 改为 10（见 redis.conf 注释），表面看采样更多更准，但实际会增加每次淘汰前的随机扫描开销。
- 当存在大量
bigkey（比如一个HASH有 50 万字段），采样 10 个 key 可能反复扫到同一结构，反而拉长单次淘汰耗时 - 建议先降回
maxmemory-samples 5测试：命令CONFIG SET maxmemory-samples 5 - 若业务允许一定精度损失（比如缓存容忍少量“非最冷”key 被淘汰），可进一步降到
3，实测在高 OPS 场景下延迟抖动明显收敛
注意：该参数只影响 LRU/LFU 类策略，allkeys-random 不受其控制。
验证淘汰线程是否真的在后台跑：盯住 lazyfreed_objects 和 CPU 使用分布
开了 lazyfree-lazy-eviction 不代表万事大吉。得确认后台线程真在干活：
- 查
INFO memory中的lazyfreed_objects：该值应随淘汰发生而稳定增长，长期为 0 说明后台线程卡住或未触发 - 用
top -H -p $(pgrep redis)看 Redis 进程内是否有多个lazyfree线程（7.2+ 支持多 lazyfree 线程），且 CPU 占用是否分散 - 若只有主线程 CPU 飙高，而
lazyfreed_objects几乎不动，大概率是maxmemory设置过低，导致每写一条都立刻触发淘汰，后台线程来不及消费
此时需结合写入节奏评估：如果峰值写入是 10k QPS，但 maxmemory 只剩 50MB 缓冲空间，那淘汰根本来不及卸载压力，本质是容量规划问题，不是配置问题。
真正卡点往往藏在「开了 lazyfree 却没看到对象释放」和「maxmemory-samples 调高后淘汰更慢」这两处，排查时优先抓这两个信号，比盲目升级或调 maxmemory-policy 更有效。
