目录

redis删除与先判断再删除的区别

redis删除与先判断再删除的区别

在Redis中,“先判断存在再删除”与“直接删除”的区别主要体现在‌ 操作效率、原子性保障、并发安全性 ‌三个方面,具体对比如下:


1. 操作效率

  • 直接删除 ‌:仅需执行 DEL 命令一次,无论键是否存在均直接操作,无额外判断步骤。时间复杂度为 O(1) ,适合高频操作场景‌。
  • 先判断存在再删除 ‌:需先执行 EXISTS 命令判断键是否存在,再根据结果执行 DEL 。若键不存在, DEL 命令仍会执行但实际无操作,导致‌ 两次网络请求和两次命令执行 ‌,增加耗时和资源消耗‌。

2. 原子性保障

  • 直接删除 ‌: DEL 命令本身是原子操作,执行过程不会被其他客户端命令打断,保证操作的完整性‌。
  • 先判断存在再删除 ‌: EXISTSDEL 为两个独立操作,在两者间隔期间可能因其他客户端修改键状态(如删除或更新),导致判断结果与实际删除操作不一致(‌ 竞态条件 ‌)‌。

3. 并发安全性

  • 直接删除 ‌:在高并发场景下,仅需关注 DEL 的返回结果(返回 1 表示删除成功, 0 表示键不存在),无需额外逻辑即可处理并发冲突‌。
  • 先判断存在再删除 ‌:若多个客户端同时判断键存在并尝试删除,可能导致重复删除或误删问题(如键已被其他客户端删除)‌。

总结对比

场景直接删除先判断存在再删除
执行次数1次命令2次命令( EXISTS + DEL
网络开销低(单次请求)高(两次请求)
原子性强(单命令原子性)弱(命令组合非原子)
适用场景无需关心键是否存在的场景需记录键状态或统计删除次数的场景
性能影响更高效效率较低,存在竞态风险

推荐方案

  • 优先选择直接删除 ‌:通过 DEL 命令的返回值( 01 )即可判断是否删除成功,无需额外操作‌。

  • ‌特殊场景处理

    若需记录键的删除状态,可结合事务(MULTI/EXEC)或Lua脚本保证操作的原子性‌。例如:

    if redis.call('EXISTS', KEYS‌:ml-citation{ref="5" data="citationList"}) == 1 then
      return redis.call('DEL', KEYS‌:ml-citation{ref="5" data="citationList"})
    else
      return 0
    end