Redis的DUMP命令是一个非常实用但又容易被误解的工具。它的作用很简单：把指定键对应的值序列化成一种紧凑的二进制格式并返回，配合RESTORE命令，可以在不依赖RDB文件、不借助第三方迁移工具的情况下，完成单个键级别的数据备份与跨实例迁移。很多初学者第一次接触它时，往往会把它当成导出文本数据的命令，结果拿到一串看不懂的二进制内容就放弃了。这篇文章就把DUMP命令的语法、原理、典型用法和常见误区一次讲清楚，帮你真正用好它。
DUMP命令的语法与基本行为
DUMP命令的语法非常简洁，只接受一个参数，即要序列化的键名。基本形式如下：
DUMP key
当键存在时，命令返回该键值的序列化结果，这是一个经过编码的二进制字符串，其中不仅包含值本身，还包含了键的数据类型、内部编码方式以及一个校验用的CRC64值。当键不存在时，命令返回nil（在redis-cli中显示为空）。这一点和GET命令返回空字符串不同，需要注意区分。
下面用一个简单的例子来观察它的行为：
127.0.0.1:6379> SET greeting "hello redis" OK 127.0.0.1:6379> DUMP greeting "\x00\x0bhello redis\t\x00\xef\x8d\xf1\xd5\xc4\xe9\xda"
从输出可以看到，返回的数据并不是纯文本的hello redis，而是带有一段头部信息、值内容以及末尾校验和的二进制串。头部字节标识了值的编码类型，末尾八个字节是CRC64校验值。理解了这个结构，你就明白为什么不能把DUMP的输出当成普通字符串来处理了。
DUMP支持所有Redis数据类型，包括字符串、列表、哈希、集合、有序集合等，甚至对带有过期时间的键也适用。不过要注意，序列化结果中不包含键名本身，也不包含过期时间，过期时间需要在RESTORE时单独指定，这是很多人踩的第一个坑，后面会详细展开。
DUMP与RESTORE配合完成数据迁移
DUMP命令单独使用意义不大，它的价值体现在与RESTORE命令的配合上。RESTORE的作用正好相反：接收一段序列化数据，将其反序列化后写入目标键。两者组合起来，就构成了Redis原生的单键迁移方案。典型流程是：在源实例执行DUMP拿到二进制数据，再到目标实例执行RESTORE写入。
RESTORE的语法稍微复杂一些，包含四个参数：
RESTORE key ttl serialized-value [REPLACE] [ABSTTL] [IDLETIME seconds] [FREQ frequency]
其中key是目标键名，ttl是过期时间（毫秒，0表示永不过期），serialized-value就是DUMP返回的数据。如果目标键已存在，必须加上REPLACE选项，否则命令会报错。下面用redis-cli演示完整的迁移过程：
# 源实例：dump出数据 127.0.0.1:6379> DUMP mykey "\x00\x0bhello redis\t\x00\xef\x8d\xf1\xd5\xc4\xe9\xda" # 目标实例：restore写入，ttl为0表示永不过期，REPLACE覆盖已有键 192.168.1.100:6380> RESTORE mykey 0 "\x00\x0bhello redis\t\x00\xef\x8d\xf1\xd5\xc4\xe9\xda" REPLACE OK
如果是在代码层面做迁移，思路也一样：先用客户端执行DUMP拿到字节流，再把它原样传给目标实例的RESTORE。关键在于bytes类型的处理，序列化数据是二进制的，传输和存储过程中必须保证不被转码或截断，否则RESTORE时会校验失败并报错。
相比使用RDB文件或者SCAN加TYPE逐条读取重建的方案，DUMP加RESTORE的优势在于精确定位到单个键，开销小、操作简单，特别适合少量热点键的紧急迁移或备份。而它的局限也很明显：不适合大批量数据搬迁，一次只能处理一个键，批量场景还是应该选择RDB、AOF或者主从复制等方案。
DUMP命令的常见误区与避坑指南
误区一：以为DUMP结果包含键名和过期时间。实际上序列化数据里只有值相关的信息。如果源键设置了TTL，迁移后不指定新的ttl，目标键就会变成永不过期，这对缓存类业务可能造成内存隐患。正确的做法是先用PTTL查询源键的剩余存活毫秒数，再把该值传给RESTORE的ttl参数，或者使用ABSTTL选项以绝对时间戳的方式传入。
误区二：把DUMP的输出当普通字符串处理。在脚本或程序中，如果把二进制数据经过UTF-8强制解码、存入不支持二进制的字段，或者在管道传输中经过文本协议转码，都会破坏数据。一旦校验和校验失败，RESTORE会返回错误，且Redis为了安全会主动清掉非法数据。务必全程以二进制安全的方式传递数据。
误区三：忽视版本兼容性问题。序列化格式中包含版本和编码信息，Redis官方保证向后兼容，即旧版本dump出的数据可以在新版本中restore，但反过来不成立。用Redis 7导出的数据恢复到Redis 3中，很可能因为不识别新的编码格式而失败。跨大版本迁移前，务必确认目标实例版本不低于源实例。
误区四：对集群环境下的hash tag理解不足。在Redis Cluster中，DUMP和RESTORE本身可以正常使用，但如果迁移时需要改变键名，注意带hash tag的键迁移后可能落到不同的槽位，业务逻辑如果依赖槽位一致性就会出问题。此外，RESTORE不允许把数据恢复到正在迁移槽位中的节点，遇到这种情况需要先等待槽位迁移完成。
误区五：用DUMP做全量备份。有人觉得循环SCAN所有键再逐个DUMP就能实现备份，理论上可行，但性能和一致性都很差。正确的全量备份手段是RDB快照、AOF文件或者主从复制，DUMP的定位始终是单键级别的精细操作。工具用对场景才能发挥价值，这一点在使用任何Redis命令时都值得牢记。
RedisDump命令DUMP命令Redis数据序列化修改时间：2026-08-31 16:30:34