开启lazyfree-lazy-eviction yes是解决内存淘汰卡顿最直接有效的方式，它仅控制maxmemory不足时的异步驱逐，与del/unlink命令无关，且需重启或config rewrite+reload生效。
开启 lazyfree-lazy-eviction yes 是解决内存淘汰引发卡顿最直接有效的配置，但它只对「内存不足触发的驱逐删除」生效，和你用什么命令删、有没有开 UNLINK 完全无关。
为什么 DEL 和 UNLINK 都救不了淘汰卡顿
淘汰是 Redis 内部自动触发的行为，走的是 evictKeysRandom 或 evictLruKeys 等函数路径，不经过客户端命令入口。所以即使你全局替换了 DEL 为 UNLINK，对淘汰场景毫无影响。
-
UNLINK只接管用户主动发起的删除（比如你执行UNLINK big_hash） - 淘汰时主线程自己遍历、选 key、释放内存，全程绕过命令分发逻辑
- 误以为开了
lazyfree-lazy-user-del就能覆盖淘汰 —— 实际上这个配置只影响DEL/UNLINK命令，和淘汰无关
lazyfree-lazy-eviction 的真实作用边界
它控制的是当 maxmemory 达到上限、Redis 根据 maxmemory-policy（如 allkeys-lru）开始踢 key 时，是否启用异步释放内存。但要注意几个硬限制：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 仅对「被选中淘汰的 key」生效；如果 key 很小（比如一个几 KB 的 String），Redis 仍会同步删，跳过异步队列 —— 因为调度开销比直接删还高
- 后台线程数量固定（默认 1 个），如果淘汰压力极大（比如每秒淘汰上百个大 Hash），异步队列可能堆积，内存释放会有延迟
- 配置名必须完整：
lazyfree-lazy-eviction，写成lazyfree-eviction或lazyfree-lazy_eviction（下划线）都会被 Redis 启动时静默忽略
配置生效前必须检查的三件事
改完 redis.conf 不等于生效，漏掉任一环节都会白配：
- 必须重启 Redis 实例，或执行
CONFIG REWRITE+CONFIG RELOAD（后者要求配置文件路径可写） - 确认当前实例没在 AOF 重写或 RDB 保存过程中 —— 这两个操作会临时禁用 lazyfree 后台线程
- 用
CONFIG GET lazyfree-lazy-eviction实时验证返回值是yes，别只信配置文件内容
真正容易被忽略的是：淘汰卡顿往往不是单次大 key 引起的，而是高频小 key 淘汰叠加后台线程争抢导致的隐性延迟。这时候光开 lazyfree-lazy-eviction 不够，还得配合调高 hz（比如从默认 10 改为 20）加快淘汰扫描节奏，减少单次扫描工作量。
