直接用 SET 循环插入慢是因为每条命令都经历一次网络往返（RTT）和Redis单线程序列化开销；正确做法是用 pipeline 批量发送，500–5000 条/批较稳妥，避免超限断连或内存溢出。
为什么直接用 SET 循环插入会慢得离谱
单条 SET 命令走的是「请求-响应」往返（RTT），网络延迟 + Redis 单线程序列化开销叠加后，10 万条数据可能耗时几十秒甚至分钟。这不是 Redis 慢，是你没绕过 TCP 往返这个瓶颈。
真实场景里，比如初始化缓存、迁移旧数据、压测预热，你根本等不起逐条确认。
- 本地 loop 调用
redis.set()→ 每次都发包、等回包、再发下一个 - 哪怕用
redis-py默认连接池，也改变不了「每条命令独立走协议栈」的本质 - Redis 服务端 CPU 可能很低，但 client 端网卡和连接数先扛不住
用 pipeline() 批量塞数据的正确姿势
Redis 的 pipeline 不是并发，而是把多条命令攒成一个 TCP 包发过去，服务端顺序执行、打包返回 —— 一次 RTT 完成 N 条操作。
注意：pipeline 是客户端行为，不依赖 Redis 版本（2.6+ 都支持），但必须用支持 pipeline 的客户端库（如 redis-py）。
- 调用
pipe = redis_client.pipeline(transaction=False)，transaction=False关键：避免 MULTI/EXEC 开销，纯批量加速 - 所有
set、hset、zadd等命令都链式调用pipe.set(...)，不加括号执行 - 最后统一
pipe.execute()触发发送，返回结果列表（顺序对应命令顺序） - 别在循环里反复
.pipeline()+.execute()—— 每次新建 pipeline 还是单次往返
# 示例：批量插入 10 万 key-value
pipe = r.pipeline(transaction=False)
for i in range(100000):
pipe.set(f"user:{i}", f"data-{i}")
pipe.execute() # 仅这一次发包
插多少条才划算？分批大小怎么定
不是越大批量越好。太大会吃光 client 内存、触发 Redis client-output-buffer-limit 限制、甚至 OOM；太小又浪费 pipeline 效益。实测下来，500–5000 条/批是较稳区间。
- 默认 Redis 配置下，单个 client 输出缓冲区上限是 1MB（
client-output-buffer-limit normal 1mb 500kb 60），超了连接会被断开 -
redis-py的execute()会把整批命令序列化进内存再发，10 万条字符串 key/value 可能占 20–30MB 内存 - 建议按 1000 条/批切分，用 for 循环包裹 pipeline，既控内存又保吞吐
- 如果 value 很大（比如 JSON 字符串 >1KB），批大小要往下压到 200–500
遇到 ConnectionError 或 ResponseError: wrong number of arguments 怎么办
这两类错误最常出现在 pipeline 场景，但原因完全不同，容易误判。
-
ConnectionError: Error 32 (Broken pipe)→ 大概率是单批太大，触发了 Redis 的 output buffer 限制，检查CONFIG GET client-output-buffer-limit和日志 -
ResponseError: wrong number of arguments→ pipeline 中混用了参数数量不对的命令，比如pipe.hset("key")少写了 field/value，或pipe.lpush("key")没给 value；错误不会在.hset()行抛出，而是在.execute()时批量报错，且提示模糊 - 调试技巧：先用小批量（如 10 条）跑通逻辑，再放大；或临时把
pipeline(transaction=False)换成pipeline(transaction=True)，看是否事务相关问题（通常不是） - 别忽略
execute()返回值 —— 它是列表，每个元素对应一条命令的结果或异常，可遍历检查
批量插入的核心就两点：把命令攒够再发，别让单次 payload 超过 Redis 和 client 的缓冲底线。真正卡住人的往往不是代码写法，而是没意识到 pipeline 的内存和协议边界在哪。
