Redis命令keys和scan

Redis的keys命令用于查找所有匹配模式的key,但由于其一次性获取所有key且可能造成阻塞,不适用于生产环境。scan命令是迭代器,分次返回结果,适合大数据量场景,但可能有数据重复。在批量删除key时,推荐使用scan配合删除操作,避免阻塞。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

Redis命令keys和scan

keys命令

Redis Keys 命令用于查找所有符合给定模式 pattern 的 key

语法: KEYS PATTERN
如:KEYS runoob*

redis 127.0.0.1:6379> SET runoob1 redis
OK
redis 127.0.0.1:6379> SET runoob2 mysql
OK
redis 127.0.0.1:6379> SET runoob3 mongodb
OK

redis 127.0.0.1:6379> KEYS runoob*
1) "runoob3"
2) "runoob1"
3) "runoob2"

缺点:

  1. 没有limit,只能一次性获取所有符合条件的key。如果数据量很大的话,就会产生无穷无尽的输出。
  2. keys命令是遍历算法,遍历全部的key,时间复杂度是O(N)。redis是单线程的,如果keys查询的时间过长,redis的其它操作会被阻塞较长时间,造成redis较长时间的卡顿。要避免在生产环境使用该命令
Warning: consider KEYS as a command that should only be used in production environments with extreme care. It may ruin performance when it is executed against large databases. This command is intended for debugging and special operations, such as changing your keyspace layout. Don't use KEYS in your regular application code. If you're looking for a way to find keys in a subset of your keyspace, consider using sets.

上面是官方文档声明,KEYS命令不能用在生产的环境中,这个时候如果数量过大效率是十分低的。同时也不要用KEYS正则匹配,官方建议直接用集合类型。

有人说 KEYS相当于关系性数据的库的 **select ***,在生产环境几乎是要禁用的。

  • KEYS命令的性能随着数据库数据的增多而越来越慢
  • KEYS命令会引起阻塞,连续的 KEYS命令足以让 Redis 阻塞

试想如果Redis阻塞超过10秒,如果有集群的场景,可能导致集群判断Redis已经故障,从而进行故障切换;

以上的情况严重会导致应用程序出现雪崩的情况。

然而,网上很多都是这么写的 redis-cli --raw keys "[key前缀]*" | xargs redis-cli del,千万别照炒,拿到生产环境上做实验。

scan命令

Redis Scan 命令用于迭代数据库中的数据库键。
SCAN 命令是一个基于游标的迭代器,每次被调用之后, 都会向用户返回一个新的游标, 用户在下次迭代时需要使用这个新游标作为 SCAN 命令的游标参数, 以此来延续之前的迭代过程。
SCAN 返回一个包含两个元素的数组, 第一个元素是用于进行下一次迭代的新游标, 而第二个元素则是一个数组, 这个数组中包含了所有被迭代的元素。如果新游标返回 0 表示迭代已结束。

语法: SCAN cursor [MATCH pattern] [COUNT count]

  • cursor - 游标。
  • pattern - 匹配的模式。
  • count - 指定从数据集里返回多少元素,默认值为 10
127.0.0.1:6379> scan 0 MATCH tony* 
1) "42"
2)  1) "tony25"
    2) "tony2519"
    3) "tony2529"
    4) "tony2510"
    5) "tony2523"
    6) "tony255"
    7) "tony2514"
    8) "tony256"
    9) "tony2511"
   10) "tony15"
127.0.0.1:6379> scan 42 MATCH tony* COUNT 1000
1) "0"
2)  1) "tony3513"
    2) "tony359"
    3) "tony4521"
    4) "tony356"
    5) "tony30"
    6) "tony320"
    7) "tony3"
    8) "tony312"

相较于keys命令,,scan命令有两个比较明显的优势

  1. scan命令的时间复杂度虽然也是O(N),但它是分次进行的,不会阻塞线程
  2. scan命令提供了limit参数,可以控制每次返回结果的最大条数

缺点:
返回的数据有可能重复,需要我们在业务层按需求去重

批量删除scan命令

因为KEYS命令的时间复杂度为O(n),而SCAN命令会将遍历操作分解成m次,然后每次去执行,从而时间复杂度为O(1)。也解决使用keys命令遍历大量数据而导致Redis服务器阻塞的情况。所以建议使用下边的指令进行批量的删除操作:
redis-cli --scan --pattern "[key前缀]*" | xargs -L 1000 redis-cli del
当前也需要关注KEY失效时间的设置高并发条件下SCAN命令的使用,否则多次使用scan命令进行正则匹配,也存在系统宕机风险。

少用KEYS命令和SCAN命令
多用集合

记一次生产事故:30万单就这样没了!
Redis 千万不要乱用KEYS命令,不然会挨打的
redis中的scan命令和keys命令
Redis Keys 命令
Redis SCAN 命令

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值