Hyperf大批量修改需分批次切片，核心是防内存溢出、超时和锁表；按500–2000条/批结合max_allowed_packet与事务时长控制，用collect()->chunk()实现内存友好分片，并可配合Parallel并发执行，同时记录进度支持断点续传。
Hyperf 中对大批量修改操作做分批次切片处理，核心是避免单次执行过多数据导致内存溢出、超时或数据库锁表。关键不在于“能不能”，而在于“怎么切得合理、执行得安全、结果可追踪”。
明确切片依据和批次大小
切片不是简单按固定数量硬拆，需结合业务与基础设施限制：
- MySQL 默认
max_allowed_packet通常为 4MB，批量 INSERT/UPDATE 的 SQL 拼接不能超过该值；建议单批控制在 500–2000 条（视单条数据体积而定） - 协程内存占用需可控，每批处理完及时释放集合引用，避免闭包长期持有大数据
- 若涉及事务，单批应在一个事务内完成，但事务不宜过长（如超过 5 秒易被 MySQL kill），建议单批事务控制在 100–500 条
用 collect() + chunk() 实现内存友好的分片
Hyperf 集合组件原生支持链式分块，适合从查询结果或数组出发的批量更新：
$userIds = [1, 2, 3, ..., 10000]; // 可能来自 DB 查询或外部输入
collect($userIds)
->chunk(500) // 每 500 个 ID 切一片
->each(function ($chunkIds) {
// 每批单独查、改、存，互不影响
$users = User::query()->whereIn('id', $chunkIds)->get();
foreach ($users as $user) {
$user->status = 'processed';
$user->updated_at = now();
}
User::upsert(
$users->map(fn($u) => $u->toArray())->toArray(),
['id'],
['status', 'updated_at']
);
});
配合协程并发提升吞吐（谨慎使用）
若各批次之间无依赖，可用 Co\run 或 Parallel 并行执行，但要注意：
- 数据库连接池需充足（
max_connections≥ 并发数 × 每批连接数） - 避免多协程同时写同一张表热点行（如更新用户余额），可能引发死锁
- 推荐方式：用
Parallel控制并发度（如 3–5），每协程内仍走单批事务
use Hyperf\Utils\Parallel;
$chunks = collect($allIds)->chunk(300)->toArray();
$results = (new Parallel(4))->until(function ($chunk) {
return User::query()->whereIn('id', $chunk)->update(['processed' => 1]) !== false;
})->wait($chunks);
记录进度与支持断点续传
万一批量任务中途失败（如网络抖动、OOM），需能从中断处继续：
- 每批执行前写一条日志或数据库记录：
batch_id、start_id、end_id、status - 使用 Redis 记录当前已处理最大 ID（适用于有序主键场景），下次从该 ID 后续读取
- 命令行任务建议加
--from-id=xxx参数，方便人工指定起点
不复杂但容易忽略。
