Redis UNLINK 为什么比 DEL 更适合删除大对象

删除一个很小的字符串键时，DEL 通常足够直接；但当键里装着很大的列表、哈希、集合或有序集合时，同步释放大量元素就可能让 Redis 主线程停在删除命令上。这个场景下，UNLINK 更适合把“键已经不可见”和“对象内存已经回收”拆开处理。

官方文档：https://redis.io/docs/latest/commands/unlink/

DEL 和 UNLINK 的成本差异在哪里

两条命令都会让键从键空间中消失，区别在于对象释放的工作放在哪里。Redis 官方文档给出的 DEL 复杂度是：要删除的键数量为 N 时为 O(N)；如果某个键保存的是列表、集合、有序集合或哈希，单个键还要按元素数量 M 执行 O(M) 的工作。

UNLINK 对每个键的命令侧移除是 O(1)，随后在另一个线程中按对象由多少内存分配组成来完成 O(N) 的回收。也就是说，它不是把删除变成“没有成本”，而是让主线程先完成键空间层面的变化，把更重的释放工作移到后台。

什么时候应该把 DEL 换成 UNLINK

判断标准不是“所有删除都用 UNLINK”，而是看删除动作是否可能在主线程上做大量复合值清理。缓存淘汰、批量清理临时键、删除大哈希或大列表时，优先考虑 UNLINK；小字符串键或你明确需要同步完成释放的维护动作，DEL 仍然可以使用。

# 删除大对象：先让键从键空间中解除，再异步回收对象
redis-cli UNLINK cache:report:2026

# 一次提交多个键；返回值是实际被解除的键数量
redis-cli UNLINK cache:a cache:b cache:c

# 小对象的同步删除仍可直接使用 DEL
redis-cli DEL session:temporary

这里的“更适合”指降低删除命令对主线程的阻塞风险，不代表后台线程永远比同步删除更快，也不代表执行后内存指标会马上下降。

UNLINK 的返回值和使用边界

UNLINK 返回被解除的键数量：不存在的键不会计入返回值。比如只存在两个键时执行三个参数，返回值可以是 2。这个数字适合判断键空间操作是否命中，不应当被当成“后台回收已完成”的确认信号。

如果业务紧接着观察内存使用量，应该把异步回收延迟考虑进去；如果部署在副本或集群环境，还要把命令路由、复制传播和各节点资源变化分开看。本文只讨论删除命令本身，不把这些现象误判成 UNLINK 没有生效。

一张表判断是否适合使用 UNLINK

常见问题

UNLINK 会不会让内存立刻下降？

不会保证立刻下降。它先解除键，再由后台线程完成对象回收；返回成功也只说明键关系已解除。

大对象都必须使用 UNLINK 吗？

不必。若删除动作需要同步完成，或对象实际很小，DEL 仍可接受。生产环境应结合对象规模、主线程延迟目标和资源观测方式决定。

可以把 UNLINK 当成异步 DEL 吗？

可以用这个比喻理解，但不要忽略返回语义：命令侧先完成，内存回收稍后完成。依赖回收完成时，需要另外设计资源观测和时序。

总结：DEL 与 UNLINK 的关键差异不在“是否删除”，而在“复合值的释放工作是否同步压在 Redis 主线程上”。删除大对象时，用 UNLINK 拆开键空间变化和后台回收，通常更符合低延迟场景。