Redis教程7-键(key)常用命令使用参考1

1.DEL

DEL key [key ...]

删除给定的一个或多个 key 。不存在的 key 会被忽略。

可用版本：>= 1.0.0

时间复杂度：

O(N)， N 为被删除的 key 的数量。

删除单个字符串类型的 key ，时间复杂度为O(1)。

删除单个列表、集合、有序集合或哈希表类型的 key ，时间复杂度为O(M)， M 为以上数据结构内的元素数量。

返回值：

被删除 key 的数量。

#  删除单个 key
redis> SET name huangz
OK

redis> DEL name
(integer) 1

# 删除一个不存在的 key
redis> EXISTS phone
(integer) 0

redis> DEL phone # 失败，没有 key 被删除
(integer) 0

# 同时删除多个 key
redis> SET name "redis"
OK

redis> SET type "key-value store"
OK

redis> SET website "redis.com"
OK

redis> DEL name type website
(integer) 3

2.DUMP

DUMP key

序列化给定 key ，并返回被序列化的值，使用 RESTORE 命令可以将这个值反序列化为 Redis 键。

序列化生成的值有以下几个特点：

• 它带有 64 位的校验和，用于检测错误， RESTORE 在进行反序列化之前会先检查校验和。
• 值的编码格式和 RDB 文件保持一致。
• RDB 版本会被编码在序列化值当中，如果因为 Redis 的版本不同造成 RDB 格式不兼容，那么 Redis 会拒绝对这个值进行反序列化操作。

序列化的值不包括任何生存时间信息。

可用版本：>= 2.6.0

时间复杂度：

查找给定键的复杂度为 O(1) ，对键进行序列化的复杂度为 O(N*M) ，其中 N 是构成 key 的 Redis 对象的数量，而 M 则是这些对象的平均大小。

如果序列化的对象是比较小的字符串，那么复杂度为 O(1) 。

返回值：

如果 key 不存在，那么返回 nil 。

否则，返回序列化之后的值。

redis> SET greeting "hello, dumping world!"
OK

redis> DUMP greeting
"x00x15hello, dumping world!x06x00Exa0Zx82xd8rxc1xde"

redis> DUMP not-exists-key    // 序列化这个不存在的key
(nil)

3.EXISTS

EXISTS key

检查给定 key 是否存在。

可用版本：>= 1.0.0

时间复杂度：O(1)

返回值：

若 key 存在，返回 1 ，否则返回 0 。

redis> SET db "redis"
OK

redis> EXISTS db
(integer) 1

redis> DEL db
(integer) 1

redis> EXISTS db
(integer) 0

4.EXPIRE

EXPIRE key seconds

为给定 key 设置生存时间，当 key 过期时(生存时间为 0 )，它会被自动删除。

在 Redis 中，带有生存时间的 key 被称为『易失的』(volatile)。

生存时间可以通过使用 DEL 命令来删除整个 key 来移除，或者被 SET 和 GETSET 命令覆写(overwrite)，这意味着，如果一个命令只是修改(alter)一个带生存时间的 key 的值而不是用一个新的 key 值来代替(replace)它的话，那么生存时间不会被改变。

比如说，对一个 key 执行 INCR 命令，对一个列表进行 LPUSH 命令，或者对一个哈希表执行 HSET 命令，这类操作都不会修改 key 本身的生存时间。

另一方面，如果使用 RENAME 对一个 key 进行改名，那么改名后的 key 的生存时间和改名前一样。

RENAME 命令的另一种可能是，尝试将一个带生存时间的 key 改名成另一个带生存时间的 another_key ，这时旧的 key(以及它的生存时间)会被删除，然后旧的 key 会改名为 another_key ，因此，新的 another_key 的生存时间也和原本的 key 一样。

使用 PERSIST 命令可以在不删除 key 的情况下，移除 key 的生存时间，让 key 重新成为一个『持久的』(persistent) key 。

更新生存时间

可以对一个已经带有生存时间的 key 执行 EXPIRE 命令，新指定的生存时间会取代旧的生存时间。

过期时间的精确度

在 Redis 2.4 版本中，过期时间的延迟在 1 秒钟之内 —— 也即是，就算 key 已经过期，但它还是可能在过期之后一秒钟之内被访问到，而在新的 Redis 2.6 版本中，延迟被降低到 1 毫秒之内。

Redis 2.1.3 之前的不同之处

在 Redis 2.1.3 之前的版本中，修改一个带有生存时间的 key 会导致整个 key 被删除，这一行为是受当时复制(replication)层的限制而作出的，现在这一限制已经被修复。

可用版本：>= 1.0.0

时间复杂度：O(1)

返回值：

设置成功返回 1 。

当 key 不存在或者不能为 key 设置生存时间时(比如在低于 2.1.3 版本的 Redis 中你尝试更新 key 的生存时间)，返回 0 。

127.0.0.1:6379> set name redis666    // 设置name
OK
127.0.0.1:6379> EXPIRE name 10    // 设置name过期时间10s
(integer) 1
127.0.0.1:6379> ttl name    // 查看剩余过期时间, 还有5s
(integer) 5
127.0.0.1:6379> get name    // 没过期, 还可以获取
"redis666"
127.0.0.1:6379> ttl name    // 已经过期了
(integer) -2
127.0.0.1:6379> get name    // 获取不到了
(nil)
127.0.0.1:6379> expire name 3000    // 重新修改过期时间, 但是name没了, 设置不成功
(integer) 0
127.0.0.1:6379> ttl name    // 无法查到过期时间了
(integer) -2
127.0.0.1:6379> set age 30    // 设置age
OK
127.0.0.1:6379> expire age 3000    // 过期时间为3000s
(integer) 1
127.0.0.1:6379> ttl age    // age的过期剩余时间
(integer) 2997
127.0.0.1:6379> ttl age    // 还有2993s才过期
(integer) 2993
127.0.0.1:6379> expire age 5000    // 重新修改过期时间为5000s
(integer) 1
127.0.0.1:6379> ttl age    // 
(integer) 4998
127.0.0.1:6379> del age    // 删除age
(integer) 1
127.0.0.1:6379> get age    // 已经删除, get不到age的值
(nil)

5.EXPIREAT

EXPIREAT key timestamp

EXPIREAT 的作用和 EXPIRE 类似，都用于为 key 设置生存时间。

不同在于 EXPIREAT 命令接受的时间参数是 UNIX 时间戳(unix timestamp)。

可用版本：>= 1.2.0

时间复杂度：O(1)

返回值：

如果生存时间设置成功，返回 1 。

当 key 不存在或没办法设置生存时间，返回 0 。

127.0.0.1:6379> set name redis666
OK
127.0.0.1:6379> expireat name 1600409820    // 设置过期时间戳, 时间为2020-09-18 14:17:00 过期(此时为2020-09-18 14:16:00)
(integer) 1
127.0.0.1:6379> get name    // 立马获取可以获取到
"redis666"
127.0.0.1:6379> ttl name    // 还有18s过期
(integer) 18
127.0.0.1:6379> ttl name    // 还有5s过期
(integer) 5
127.0.0.1:6379> ttl name    // 已经过期了
(integer) -2
127.0.0.1:6379> get name    // 获取不到了, 被删除
(nil) 
127.0.0.1:6379>

6.KEYS

KEYS pattern

查找所有符合给定模式 pattern 的 key 。

KEYS * 匹配数据库中所有 key (redis默认数据库是0)。

KEYS h?llo 匹配 hello ， hallo 和 hxllo 等。

KEYS h*llo 匹配 hllo 和 heeeeello 等。

KEYS h[ae]llo 匹配 hello 和 hallo ，但不匹配 hillo 。

特殊符号用  隔开

KEYS 的速度非常快，但在一个大的数据库中使用它仍然可能造成性能问题，如果你需要从一个数据集中查找特定的 key ，你最好还是用 Redis 的集合结构(set)来代替。

可用版本：>= 1.0.0

时间复杂度：O(N)， N 为数据库中 key 的数量。

返回值：符合给定模式的 key 列表。

redis> MSET one 1 two 2 three 3 four 4  # 一次设置 4 个 key
OK
redis> KEYS *o*　　// 匹配包含o的key
1) "four"
2) "two"
3) "one"
redis> KEYS t??    // 匹配t开头而且后面有两位的key
1) "two"
redis> KEYS t[w]*    // 匹配t开头, 第二位是w 后面还有一位的key
1) "two"
redis> KEYS *  # 匹配数据库内所有 key
1) "four"
2) "three"
3) "two"
4) "one"

7.MIGRATE

MIGRATE host port key destination-db timeout [COPY] [REPLACE] [KEYS key]

• host：目标Redis的IP地址
• port：目标Redis的端口
• key：Redis 3.0.6 后如果需要迁移多个键，此处为空字符串""
• destination-db：目标Redis的数据库索引, redis默认使用0数据库
• timeout：迁移的超时时间（单位为毫秒)
• COPY ：不移除源实例上的 key 。
• REPLACE ：替换目标实例上已存在的 key
• keys：如果要删除多个建，填写keys, 例如 keys key1 key2 key3

将 key 原子性地从当前实例传送到目标实例的指定数据库上，一旦传送成功， key 保证会出现在目标实例上，而当前实例上的 key 会被删除。

这个命令是一个原子操作，它在执行的时候会阻塞进行迁移的两个实例，直到以下任意结果发生：迁移成功，迁移失败，等到超时。

命令的内部实现是这样的：它在当前实例对给定 key 执行 DUMP 命令 ，将它序列化，然后传送到目标实例，目标实例再使用 RESTORE 对数据进行反序列化，并将反序列化所得的数据添加到数据库中；当前实例就像目标实例的客户端那样，只要看到 RESTORE 命令返回 OK ，它就会调用 DEL 删除自己数据库上的 key 。

timeout 参数以毫秒为格式，指定当前实例和目标实例进行沟通的最大间隔时间。这说明操作并不一定要在 timeout 毫秒内完成，只是说数据传送的时间不能超过这个 timeout 数。

MIGRATE 命令需要在给定的时间规定内完成 IO 操作。如果在传送数据时发生 IO 错误，或者达到了超时时间，那么命令会停止执行，并返回一个特殊的错误： IOERR 。

当 IOERR 出现时，有以下两种可能：

• key 可能存在于两个实例
• key 可能只存在于当前实例

唯一不可能发生的情况就是丢失 key ，因此，如果一个客户端执行 MIGRATE 命令，并且不幸遇上 IOERR 错误，那么这个客户端唯一要做的就是检查自己数据库上的 key 是否已经被正确地删除。

如果有其他错误发生，那么 MIGRATE 保证 key 只会出现在当前实例中。（当然，目标实例的给定数据库上可能有和 key 同名的键，不过这和 MIGRATE 命令没有关系）。

可选项：

• COPY ：不移除源实例上的 key 。
• REPLACE ：替换目标实例上已存在的 key

可用版本：>= 2.6.0

时间复杂度：

这个命令在源实例上实际执行 DUMP 命令和 DEL 命令，在目标实例执行 RESTORE 命令，查看以上命令的文档可以看到详细的复杂度说明。

key 数据在两个实例之间传输的复杂度为 O(N)

返回值：

迁移成功时返回 OK ，否则返回相应的错误。

示例:

先启动两个 Redis 实例，一个使用默认的 6379 端口，一个使用 7777 端口

为了演示和操作以及理解方便, 我电脑上之前还有一个redis, 版本是3.2.100, 将其启动, 并指定端口为7777

$ redis-server.exe --port 7777

然后用客户端连上 7777端口的实例，在6379设置一个键，然后将它迁移到 7777 端口的实例上：

$ redis-cli.exe -p 7777　　// 连接上端口为7777的redis
127.0.0.1:7777> ping
PONG

如上, 已经连接上了本机另一个redis, 端口号为7777

但是很不幸, 执行的之后发现无论怎么执行, 都会报错, 如下

127.0.0.1:6379> keys *　　// 此时没有任何key
(empty list or set)
127.0.0.1:6379> set name redis666888    // 设置key name
OK
127.0.0.1:6379> keys *    // 只存在一个name
1) "name"
127.0.0.1:6379> exists name    // name存在
(integer) 1
127.0.0.1:6379> get name    // 可以获取到name的值
"redis666888"

如上, 设置了name属性, 迁移name如下,

127.0.0.1:6379> migrate 127.0.0.1 7777 name 0 100    // 指定迁移name, 不成功
(error) ERR Target instance replied with error: ERR DUMP payload version or checksum are wrong
127.0.0.1:6379> migrate 127.0.0.1 7777 "" 0 100 keys name    // 使用keys的方式迁移name, 也不成功
(error) ERR Target instance replied with error: ERR DUMP payload version or checksum are wrong

怀疑是版本问题, 所以重新启动一个同样版本的redis, 依然进入版本Redis-x64-5.0.9的目录下, 重新启动一个redis, 6379已经启动了, 重新再启动 一个redis指定端口号7777

$ redis-server.exe --port 7777

连接端口7777的redis, 因为默认使用db 0的数据库, 为了测试方便, 我们是用db 1的数据库

$ redis-cli.exe -p 7777
127.0.0.1:7777> ping
PONG
127.0.0.1:7777> select 1　　// 改为使用db 1的数据库
OK
127.0.0.1:7777[1]> ping
PONG
127.0.0.1:7777[1]>

此时再此在6379中执行name的迁移, 为了测试[KEYS Key]的使用, 先多添加几个key, 如下

127.0.0.1:6379> set age 66
OK
127.0.0.1:6379> set tel 110
OK
127.0.0.1:6379> keys *    // 此时6379中一个3个key
1) "tel"
2) "age"
3) "name"
127.0.0.1:6379> migrate 127.0.0.1 7777 name 1 100    // 时间超时为100ms, 迁移到端口为7777的db为1的redis数据库中
OK
127.0.0.1:6379> keys *    // name已经没了
1) "tel"
2) "age"
127.0.0.1:6379> migrate 127.0.0.1 7777 "" 1 100 keys age tel    // 使用keys key的命令, 一次迁移多个key, age和tel
OK
127.0.0.1:6379> keys *    // age 和 tel也没了
(empty list or set)
127.0.0.1:6379>

此时再去7777端口查看db 1中的key, 是否多了name, age 和 tel

127.0.0.1:7777[1]> keys *
1) "tel"
2) "name"
3) "age"
127.0.0.1:7777[1]> get tel
"110"
127.0.0.1:7777[1]> get name
"redis666888"
127.0.0.1:7777[1]> get age
"66"
127.0.0.1:7777[1]>

如上, name和age, tel 分别使用两种方式从6379中迁移到了7777中, 刚才的错误果然是因为版本好的问题导致的......