Redis 的 MSET 命令用于在单个请求中同时写入多个键值对，语法为 MSET key value [key value ...]。如果业务中需要一次性初始化一组缓存、批量刷新配置项，或者把多个计算结果写回 Redis，逐条调用 SET 会产生大量网络往返，而 MSET 能把 N 次写入压缩成一次命令处理。
MSET 的写入过程是原子性的。命令格式合法时，所有键值对会一次性写入；格式错误时，整个命令不会执行。这与管道中多条 SET 命令的行为不同，管道只是把命令打包发送，Redis 仍然逐条执行，中间某条失败不会影响其他命令。
一、MSET命令的基本语法与返回值
MSET 的参数必须成对出现，每一对包含一个键和一个值，键和值之间用空格分隔。如果参数个数是奇数，Redis 会直接返回参数数量错误，此时不会写入任何数据。这个特性让 MSET 在批量写入时具备天然的一致性：要么全部成功，要么全部失败。
下面是一个正常执行的例子：
MSET user:1:name "Alice" user:1:age "30" user:1:city "Beijing"
返回结果为 OK，表示所有键值对已经写入。时间复杂度是 O(N)，N 为键值对的数量。虽然 MSET 内部仍然需要遍历所有键执行写入，但由于省去了多次命令解析、网络传输和客户端等待，整体耗时通常远低于逐条 SET。
如果键已经存在，MSET 会直接覆盖旧值。字符串类型的键值可以是普通文本、整数、JSON 字符串或序列化后的二进制数据。需要特别区分的是 MSETNX，它只有在所有键都不存在时才会写入，只要有一个键已经存在，整个命令都会放弃执行。原子性覆盖和原子性初始化是两类不同的需求，选择命令时要看清楚。
二、MSET与管道、事务的性能对比
很多团队在需要批量写入时会习惯性地选择管道，因为 pipeline 可以一次发送多条命令。但从 RTT 的角度看，MSET 和 pipeline 都能把多次往返压缩成一次，真正的差异在执行行为和原子性上。
管道中的多条 SET 命令会被服务端按顺序逐条执行，任何一条命令失败都不会阻止其他命令继续运行。这种模式适合需要混合多种命令、或者每条命令都有自己的过期时间、NX 条件等场景。而 MSET 只做一件事：批量覆盖字符串键。它的优势在于原子性，适合那些必须全部成功或全部失败的写入。
下面通过 Python 客户端对比两种写法：
import redis
r = redis.Redis(host='127.0.0.1', port=6379, decode_responses=True)
# 使用 MSET 一次写入多个键值对
r.mset({'user:1:name': 'Alice', 'user:1:age': '30', 'user:1:city': 'Beijing'})
# 使用 pipeline 批量写入
pipe = r.pipeline()
pipe.set('user:2:name', 'Bob')
pipe.set('user:2:age', '25')
pipe.set('user:2:city', 'Shanghai')
pipe.execute()
在高延迟网络环境下，比如客户端和 Redis 服务器跨地域部署，MSET 的优势会进一步放大。假设一次 RTT 是 20 毫秒，写入 10 个键，逐条 SET 至少需要 200 毫秒，MSET 只需要一个 RTT 外加服务端几微秒的处理时间。即使使用 pipeline，节省的也只是网络往返，服务端仍然要逐条解析和执行命令。
事务的 MULTI/EXEC 也能保证原子性，但它的成本更高。事务需要先把命令放入队列，执行 EXEC 时再统一提交，并且事务期间其他客户端不能插入命令。对于单纯的批量字符串覆盖，MSET 比事务更轻量，逻辑也更直观。
三、使用MSET的注意事项与常见陷阱
第一个容易忽略的问题是 Redis Cluster 的跨槽限制。在集群模式下，MSET 要求所有键都落在同一个哈希槽。如果键名分散在不同槽，命令会直接失败并返回 CROSSSLOT 错误。例如：
MSET user:1:name "Alice" user:2:name "Bob" (error) CROSSSLOT Keys in request don't hash to the same slot
解决办法是使用 hash tag，让 Redis 只根据大括号内的部分计算槽位。比如把键名写成 {user:1}:name 和 {user:1}:age，它们会落到同一个槽。需要注意，hash tag 会改变键的分布策略，如果大量键都使用相同的 tag，可能造成数据倾斜。
第二个问题是键的过期时间。MSET 会直接覆盖旧值，并且不会保留原有键的 TTL。比如原本 user:1:session 设置了 30 分钟过期，执行 MSET 覆盖后，这个键会变成永久有效。如果需要保留过期时间，建议改用 pipeline，先 SET 再 EXPIRE，或者使用 Lua 脚本把设置值和设置过期时间打包成原子操作。
第三个问题是单次写入的数据量。MSET 是 O(N) 操作，N 越大，服务端阻塞事件循环的时间就越长。如果一次性写入几万个键，或者单个 value 达到几 MB，Redis 会因为命令解析和内存分配出现明显延迟，甚至影响其他请求。生产环境建议分批执行，每批控制在几百个键以内，value 的体积也要评估。
另外，MSET 只能处理字符串类型。如果业务中有哈希、列表、集合等复杂数据结构，MSET 无法直接写入。这时可以选择 pipeline 逐条执行 HSET、LPUSH 等命令，或者用 Lua 脚本实现跨类型的批量原子操作。理解这些边界，可以避免在错误的场景下强行使用 MSET。
四、什么场景下应该优先使用MSET
MSET 最典型的应用场景是缓存预热和配置批量加载。应用启动时需要把数据库中的基础数据一次性刷入 Redis，这类数据通常是纯字符串键值对，没有复杂的过期策略，也不涉及跨槽问题。此时用 MSET 可以显著缩短启动时间。
另一个常见场景是数据汇总后的批量回写。例如定时任务统计出一批结果，需要同时更新多个指标键。只要这些键都在同一个 Redis 实例或同一个哈希槽内，MSET 就是最直接的选择。
如果写入过程中还需要根据旧值做判断，比如只在旧值小于某个阈值时才更新，MSET 就无法满足条件。这种情况下可以使用 Lua 脚本，在脚本内部读取旧值、判断后再写入，既保证原子性又保留业务逻辑。相比事务，Lua 脚本的执行效率更高，因为它把整个逻辑压缩成一次命令执行。
Redis MSET批量设置键值对修改时间：2026-10-01 07:39:47