Hyperf 3.0 大批量数据修改需四层协同：协程并发分片（每批100–500行）、连接池调优（max_connections=CPU×4～6）、写操作异步化（async-queue+分片协程）、CQRS读写分离（主库写+从库/Redis查）。
Hyperf 3.0 中优化大批量数据修改，核心不是靠“一次改更多”，而是通过协程调度、连接池控制、异步解耦和分片执行四层协同来规避阻塞、减少锁争用、提升吞吐。直接在事务里循环 update 万条记录，在 Hyperf 3.0 下反而会拖垮整个协程调度器。
用协程并发替代串行循环
传统 foreach + DB::update 在协程中仍是同步阻塞操作，会卡住当前协程。正确做法是把批量任务拆成小批次，并发调度：
- 每批控制在 100–500 行（视单行更新复杂度而定），避免单次 SQL 过长或锁表时间过久
- 用 co::run 或 Hyperf\Coroutine\Coroutine::create 启动多个协程并行处理不同批次
- 配合 Hyperf\Database\Connection::transaction 每批独立事务，失败只回滚本批，不影响其余
调优数据库连接池防止耗尽
大批量修改最常触发的错误是 “Too many connections” 或 “wait timeout”。Hyperf 3.0 的 MySQL 连接池必须针对性配置：
- max_connections 建议设为 CPU 核数 × 4～6（非固定 10），例如 8 核服务器可设 32～48
- min_connections 可设为 5～10，避免冷启动时频繁建连
- wait_timeout 保持默认 3.0 秒即可，协程任务应短平快；若需长事务，单独配一个专用连接池
- 务必关闭 auto_close（默认 false），防止协程间误关连接
写操作异步化，主流程不等待
如果业务允许最终一致性（如后台数据同步、报表刷新、库存预占后校验），应将大批量修改下沉为异步任务：
- 使用 hyperf/async-queue 投递 Job，任务体内部再做分片+协程并发
- 配置 processes = CPU 核数 × 2，concurrent.limit = 20～30，避免 Task Worker 被单个大任务占满
- 任务内优先走 Redis pipeline 或 MySQL REPLACE INTO / INSERT ... ON DUPLICATE KEY UPDATE，比逐条 UPDATE 更高效
结合 CQRS 分离读写压力
当大批量修改伴随高频查询（如运营后台边改边看统计），必须隔离读写链路：
- 写操作走主库 + 事务 + 事件发布（如 ProductStockUpdated）
- 查操作走只读从库或 Redis 缓存，缓存更新由事件监听器触发（ProductStockUpdatedListener）
- 避免在写事务中调用任何 QueryService，防止从库连接被写事务阻塞
