UNLINK可替代DEL异步删除大Key，避免主线程阻塞；需开启lazyfree-lazy-user-del配置，但WATCH监控、refcount>1等场景仍同步执行。
大Key删除卡主线程？DEL 确实会阻塞
Redis 是单线程处理命令的，DEL 删除一个大 Key（比如含几百万成员的 Hash、超长 String 或巨型 ZSet）时，会同步释放所有内存，期间无法处理其他请求。现象就是：延迟陡增、INFO commandstats 里 del 耗时飙升、监控看到 used_cpu_sys 或 used_memory_peak_human 异常波动。
根本原因不是“删得慢”，而是“删得不异步”——DEL 必须等整个对象彻底清理完才返回，主线程全程被占。
- 典型大 Key 场景：
String> 10MB、Hash/Set/ZSet成员数 > 10 万、List长度 > 50 万 -
DEL时间 ≈ O(N)，N 是底层数据结构实际元素个数或字节数，不是 key 数量 - 即使开了
lazyfree-lazy-user-del yes，DEL默认仍走同步逻辑（该配置只影响部分内部命令，如FLUSHDB）
用 UNLINK 替代 DEL，让释放异步化
UNLINK 是 Redis 4.0+ 引入的命令，语义和 DEL 完全一致（返回被删 key 数），但内部把“内存释放”交给后台线程（lazyfree 线程池）异步执行，主线程只做 key 的元数据摘除，几乎瞬时返回。
它不是“不释放”，而是“不卡你”。只要确保 lazyfree-lazy-user-del 开启（默认是 no，必须显式配），UNLINK 就能真正生效：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 检查是否开启：
CONFIG GET lazyfree-lazy-user-del→ 返回["lazyfree-lazy-user-del","yes"]才有效 - 临时开启（重启前）：
CONFIG SET lazyfree-lazy-user-del yes - 写入
redis.conf永久生效：lazyfree-lazy-user-del yes - 注意：
UNLINK对不存在的 key 返回 0，和DEL行为一致，业务代码无需改逻辑
UNLINK 不是万能的：这些情况它也同步删
UNLINK 异步释放的前提是“对象能被安全移交后台线程”。以下情况它会自动退化为同步 DEL，不报错但失去意义：
- 目标 key 正被其他客户端通过
WATCH监控（事务上下文未结束） - key 的 refcount > 1（例如被
OBJECT REFCOUNT查到有多个引用，或正参与RENAME等操作） - 底层分配器不支持异步释放（极少见，如某些自定义 jemalloc 编译选项）
- 内存已极度紧张，后台线程主动拒绝接收新任务（此时
INFO memory中mem_not_counted_for_lazyfree可能上升）
验证是否真异步：在删除前后快速执行 INFO memory，观察 used_memory_human 是否缓慢下降（而非瞬间回落），同时 lazyfree_pending_objects 计数会先升后降。
生产环境替换建议与风险点
直接全局把 DEL 换成 UNLINK 是最简方案，但要注意边界：
- 客户端 SDK 需支持 Redis 4.0+ 协议；老版本 Jedis/Lettuce 可能不识别
UNLINK命令（报ERR unknown command），升级或加兼容判断 - 不要在 Lua 脚本里用
UNLINK—— 脚本内所有命令强制同步执行，UNLINK在脚本中等效DEL - 监控需补充
lazyfree_pending_objects和lazyfreed_objects指标，避免后台队列积压导致内存延迟释放甚至 OOM - 对超巨型 Key（如 1GB+ String），即使
UNLINK也建议拆分删除（如用STRALGO LCS分段或先RESTORE到新 key 再删旧 key）
真正容易被忽略的是：后台线程释放速度取决于 CPU 和内存碎片状况，高峰期若 lazyfree_pending_objects 持续 > 1000，说明释放跟不上删除节奏，得查是不是删得太猛，或者内存本身快满了。
