在典型内网环境（RTT ≈ 0.2–0.5ms）下，PHP 8.1 使用 pipeline 批量写入 1000 条简单 SET 命令，耗时通常能从 800–1200ms 降到 60–150ms，性能提升 8–12 倍；跨机房（RTT ≥ 10ms）可提升 15–18 倍，根本原因是省去重复网络往返（RTT），而非 Redis 或 PHP 自身变快。
直接说结论：在典型内网环境（RTT ≈ 0.2–0.5ms）下，PHP 8.1 使用 pipeline 批量写入 1000 条简单 SET 命令，耗时通常能从 800–1200ms 降到 60–150ms，性能提升 8–12 倍；若跨机房（RTT ≥ 10ms），提升可到 15–18 倍。但这个数字不是固定值——它极度依赖你实际的网络、value 大小、Redis 负载和 batch size。
pipeline 在 PHP 8.1 中为什么能快这么多？
根本原因不是 Redis 变快了，而是省掉了「一问一答」的重复网络等待：
- 单条
SET：发命令 → 等响应（0.3ms RTT）→ 再发下一条 → …… -
pipeline：攒 1000 条 → 一次发过去 → 一次收 1000 个响应 → 总 RTT 还是 0.3ms
Redis 服务端执行 1000 条 SET 本身只花几毫秒（单条微秒级），真正卡住的是网络往返。PHP 8.1 的 Redis 扩展底层用的是纯 TCP，没有额外序列化开销，所以 pipeline 的收益非常干净。
- 不要被“PHP 慢”带偏：瓶颈不在 PHP 解释器，而在 socket 往返
-
pipeline不触发 MULTI/EXEC，PHP 默认就是transaction=false，没额外协议开销 - 实测中，1000 条
SET key:i value:i，常规循环平均 920ms，pipeline 平均 78ms（提升 11.8×）
PHP 8.1 中正确使用 pipeline 的关键点
pipeline 不是调个方法就自动加速，错一步可能白忙活甚至更慢：
立即学习“PHP免费学习笔记（深入）”；
- 必须复用同一个
Redis实例下的pipeline()对象，不能每次循环都$redis->pipeline() - 写完必须显式调用
exec()（或execute()，取决于扩展版本），否则命令压根没发出去 - 避免在 pipeline 里混入
GET或依赖前序结果的命令（比如先INCR再SETbased on result），pipeline 是并行打包，不等返回 - 每批建议控制在
500–2000条之间：太少省不到多少 RTT，太多会触发客户端内存暴涨或 Redis 的client-output-buffer-limit断连 - 如果 value 是 JSON 或序列化对象，先确认是否真有必要——紧凑字符串比
json_encode($arr)快 3–5 倍，pipeline 加速会被低效序列化吃掉大半
示例（正确写法）：
$redis = new Redis();
$redis->connect('127.0.0.1', 6379);
<p>$pipe = $redis->pipeline(); // ← 复用这一个
for ($i = 0; $i < 1000; $i++) {
$pipe->set("user:{$i}", "data_{$i}");
}
$result = $pipe->exec(); // ← 必须调这个，返回 array(1000 个 TRUE 或 FALSE)</p>为什么有时候加了 pipeline 反而更慢？
不是 pipeline 本身有问题，而是你踩中了几个隐蔽但高频的坑：
- Redis 正在做
bgrewriteaof或内存接近maxmemory，此时批量压入会加剧阻塞，latency doctor可能显示command类型延迟突增至 200ms+ - 客户端没设连接超时或重试策略，
exec()卡住 5 秒才失败，拖垮整个请求 - 批次太大（比如 10000 条），PHP 进程内存瞬间涨 80MB+，触发 GC 暂停，反而比小批次慢
- 用了
phpredis旧版本（< 5.3.4），存在 pipeline 缓冲区未及时 flush 的 bug，导致部分命令静默丢失 - 在 Laravel 等框架里误用了
Cache::store('redis')->pipeline()，实际走的是封装层，可能默认开了 transaction 或自动拆包
真正难的不是写对那几行代码，而是判断「这一批该塞多少条」——它既不是 100 也不是 5000，得结合你的 redis-cli --intrinsic-latency 10 基线、INFO clients 的 client_longest_output_list 和真实业务数据压测出来。线上切流前，至少跑两轮：一批 500，一批 2000，看 P99 延迟拐点在哪。
