DEL / UNLINK 是什么
DEL 同步删除键并返回真正删掉的键数量；UNLINK（Redis 4.0 起）做同样的删除，但把内存回收交给后台线程异步完成。对客户端而言两者都立即返回、键立刻不可见，区别在大 key 场景：DEL 会在主线程回收整块内存造成阻塞，UNLINK 把这一步挪到后台。
基本信息
| 适用版本 | DEL 全版本；UNLINK 需 Redis 4.0+ |
|---|---|
| 语法 | DEL key [key ...] / UNLINK key [key ...] |
| 返回值 | 实际删除的键数量，不存在的键不计入 |
| 耗时特征 | DEL 随元素数增长；UNLINK 立即入队返回 |
| 相关命令 | EXISTS / TYPE / MEMORY USAGE / SCAN |
典型使用场景
- 清理业务键：按前缀定位后批量删除，DEL 支持一次带多个键
- 运维回收大 key：几十 MB 的 Hash/ZSet 用 UNLINK 避免主线程卡顿
- 缓存失效：写库后删缓存，即 Cache Aside 的删除动作
- 幂等判断：用返回值确认键此前是否存在，做一次性消费
- 集群分片清理：按槽或前缀分批扫描后再删，避免单条命令过大
- 排查残留键：删除后确认返回值，区分真删掉与本来就不存在
- 下线业务回收：确认流量已停后再批量清理，避免误删仍在使用的键
示例
示例
SET k1 v1
SET k2 v2
DEL k1 k2 # 返回 2
DEL k1 # 返回 0，键已不存在
# 大 key 场景改用 UNLINK
UNLINK big:sorted:set # 立即返回 1，内存由后台线程回收
MEMORY USAGE big:sorted:set # 返回 nil，键已不可见（内存未立刻归还）
SCAN 0 MATCH 'cache:user:*' COUNT 100 # 用游标分批找键，禁止线上 KEYS删除方式对照
| 方式 | 回收时机 | 阻塞风险 |
|---|---|---|
| DEL | 主线程同步释放内存 | 大 key 会阻塞数百毫秒到数秒 |
| UNLINK | 后台线程异步释放 | 几乎不阻塞，内存稍后归还 |
| 过期删除 | 惰性加定期两种触发 | 视键大小同样可能造成毛刺 |
| FLUSHDB | 整库一次清空 | 生产环境高危，需二次确认 |
大 key（几十 MB 的 Hash/ZSet）用 DEL 会卡主线程；线上清理一律用 UNLINK，或按字段做 HDEL/ZREM 渐进式删除。
UNLINK 返回成功只说明键逻辑上已删，内存由后台释放；INFO memory 里的 used_memory 下降有延迟，做容量评估时要留出缓冲。