Hyperf高并发批量修改需针对性配置连接池：①min_connections设8–16，max_connections按数据库max_connections的60%–70%设；②Swow下须删旧pool、用专用结构并设check_interval≥3000；③connect_timeout提至5.0，wait_timeout设5.0–8.0，max_idle_time≤30.0，禁用PDO::ATTR_PERSISTENT；④建议分片更新、隔离batch_writer池、显式控制预处理；⑤运行时验证连接池启用状态并监控idle/active指标。
要让 Hyperf 在高并发下稳定执行批量修改（如 update、insert on duplicate key update 或事务内多条 UPDATE），连接池不能只靠“加大 max_connections”硬扛，而需结合数据库承载力、协程生命周期、SQL 特性做针对性配置。
按业务压力分级设置连接池大小
批量修改通常伴随短时高吞吐、单次耗时略长的特点，连接池需避免“挤占+阻塞”：
- min_connections 设为 8–16：保障低峰期也有足够空闲连接可立即复用，避免批量任务启动时排队建连
-
max_connections 不直接对标 CPU 核数，而参考目标数据库的
max_connections值 —— 建议设为其 60%～70%，例如 MySQL 实例限制为 500，则连接池最大设 300～350 - 若使用 Swow 引擎，必须删掉旧
pool一级配置，改用 Swow 专用结构，并设check_interval >= 3000（毫秒），否则心跳异常导致连接泄漏
适配批量操作的超时与空闲策略
批量 SQL 执行时间波动大，连接池参数需放宽容忍度，同时防止僵死连接堆积：
-
connect_timeout 提至
5.0：应对主从延迟或 VIP 切换初期的短暂不可达 -
wait_timeout 设为
5.0～8.0：避免大量并发请求在连接池满时长时间挂起，改由上层限流或降级处理 -
max_idle_time 严格控制在
30.0秒以内：尤其在双主或分库场景下，强制回收空闲连接，确保后续批量请求能命中新可用节点 - 禁用
PDO::ATTR_PERSISTENT：持久连接在批量写入后易残留未提交事务或锁状态，协程复用时引发不可预知行为
规避批量写入引发的连接池瓶颈
批量修改本身不是连接池问题的根源，但会放大配置不合理带来的副作用：
- 避免在事务中混合读写大批量数据 —— 可拆分为“先查 ID 列表 → 分片批量更新”，减少单事务持有连接时间
- MySQL 8.0+ 批量写入建议显式关闭模拟预处理：
'options' => [PDO::ATTR_EMULATE_PREPARES => false]；MySQL 5.7 若遇Packet too large，则需同步调大max_allowed_packet并设PDO::ATTR_EMULATE_PREPARES => true - 对高频批量任务，可单独配置一个语义化连接池（如
batch_writer），与查询池物理隔离，防止慢更新拖垮读请求
运行时验证与兜底机制
配置生效≠稳定运行，需配套可观测手段：
- 通过
Db::connection('xxx')->getPdo()检查实际连接是否启用连接池（返回Hyperf\Database\Connection实例，非原生 PDO） - 压测时监控
hyperf.database.pool.idle和hyperf.database.pool.active指标，若 idle 长期为 0 且 active 接近 max，说明池子过小或有连接泄露 - 在关键批量接口入口加
try/catch (Throwable $e)，捕获No available connection后主动触发重试（带退避）或切到异步队列降级
