单条 SET 写 Redis 慢是因每次请求都经历完整 TCP 往返，10 万次 0.5ms 延迟累计达 50 秒；Pipeline 通过打包多命令为单次往返省去 99% RTT，但非事务、不保证原子性，Python 中需显式设 transaction=False 并调用 execute()。
为什么单条 SET 写 Redis 慢得明显？
因为每次 SET 都要走一次 TCP 往返：客户端发命令 → 服务端处理 → 返回 OK。网络延迟（哪怕只有 0.5ms）乘上 10 万次，就是 50 秒。这不是 Redis 慢，是「请求太碎」。
Pipeline 的核心不是让 Redis 跑得更快，而是把多个命令打包成一个 TCP 包发过去，服务端批量执行、批量回包——省掉中间 99% 的 RTT。
注意：pipeline 不是事务，不保证原子性；失败的命令不会中断后续执行，错误结果仍会返回在响应列表里。
Python 中用 redis-py 正确开启 Pipeline 的写法
别直接用 r.pipeline() 就完事——默认是 transaction=True，会额外加 MULTI/EXEC 开销，反而拖慢纯写入场景。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 必须显式传
transaction=False：r.pipeline(transaction=False) - 写完记得调
execute()，否则命令根本没发出去 - 每批不宜过大（建议 1000–5000 条），太大可能触发客户端内存暴涨或服务端
client-output-buffer-limit限制 - 避免在 pipeline 里混用读命令（如
GET），否则无法利用响应合并优势
pipe = r.pipeline(transaction=False)
for i in range(10000):
pipe.set(f"key:{i}", f"value:{i}")
result = pipe.execute() # 批量发出，一次性收 10000 个响应
什么时候 Pipeline 反而更慢？
Pipeline 不是银弹。以下情况它帮不上忙，甚至添乱：
- 数据量小（
- 命令之间有依赖（比如后一条要用前一条的
GET结果）：Pipeline 无法串行等待，得拆成多段或改用 Lua - 用了
WATCH或需要强一致性的场景：Pipeline 不支持乐观锁，必须退回到单命令 + 重试逻辑 - Redis 实例本身已高负载（CPU >80% 或内存接近 maxmemory）：批量压入可能加剧阻塞，观察
latency doctor输出是否出现command类型延迟尖峰
比 Pipeline 更快的替代方案：redis-cli --pipe 和 RESTORE
如果只是「灌数据」且能接受离线准备格式，绕过 Python 层更高效：
-
redis-cli --pipe直接从标准输入读取 RESP 协议格式命令流，无序列化/反序列化开销。适合从文件或管道导入：cat commands.txt | redis-cli --pipe - 对已有 Redis 数据做迁移或备份恢复，用
RESTORE（配合DUMP）批量还原整个 key，比逐 keySET快 3–5 倍，但要求目标 key 不存在且不校验 TTL 兼容性 - 集群环境下，
pipeline默认不自动分片——你得自己按 key hash 路由到对应节点，否则会报CROSSSLOT错误；而redis-cli --pipe同样不处理分片，需前置拆分命令流
真正卡点往往不在「怎么发」，而在「发之前有没有预计算好 key 分布」「失败后要不要补漏」「内存够不够缓存整批命令」——这些细节比选 pipeline 还关键。
