连接池大小不能只看CPU核数，应结合IO阻塞、协程复用、磁盘类型及并发事务数综合设定；SSD环境建议CPU核数×2～×4，HDD可放宽至×6～×8，并需联动协程池与Worker数调优。
连接池大小不能只看CPU核数，但它是起点
直接套用 max_connections = CPU核心数 × 2 在 Hyperf 生产环境大概率出问题。这个公式只适用于纯 CPU 密集、无 IO 阻塞的极简场景——而真实业务里，SQL 查询、网络调用、磁盘写入全在拖慢单个协程，导致连接被长期占用。所以核数只是下限参考，不是上限依据。
更关键的是：Hyperf 的协程模型让「连接」和「协程」并非 1:1 绑定；一个连接可被多个协程复用（只要不跨事务），但事务内必须独占。因此连接池大小要同时扛住「并发事务数」+「非事务查询峰值」。
-
min_connections设为5左右即可，避免冷启动时频繁建连；设太高会白占 MySQL 连接数 -
max_connections建议从CPU核心数 × 4起步（如 8 核 → 32），再结合压测调整；超过50必须确认 MySQL 的max_connections全局值是否足够（默认常为 151） -
wait_timeout别设成0或过大，3.0是安全值；设太小会导致协程刚排队就超时抛异常
为什么 SSD 服务器反而要配更小的连接池？
很多人看到“SSD 更快”，第一反应是把 max_connections 拉到 100+，结果数据库 CPU 直冲 95%，TPS 不升反降。原因在于：SSD 消除了磁盘寻址等待，协程在 SQL 执行阶段几乎不阻塞，线程/连接闲置时间变长，上下文切换开销反而成了瓶颈。
Oracle Real World Performance Group 的实测数据很说明问题：9600 并发线程下，把中间件连接池从 2048 降到 96，SQL 平均执行耗时从 77ms 降到 2ms，队列等待从 33ms 降到 1ms——吞吐翻倍，等待归零。
- SSD 环境建议
max_connections控制在CPU核心数 × 2 ～ × 4区间，优先往低配 - HDD 环境可放宽至
× 6 ～ × 8，但需同步监控 MySQL 的Threads_running和innodb_row_lock_waits - 无论磁盘类型，一旦
Db::getPdo()->getAttribute(PDO::ATTR_CONNECTION_STATUS)显示连接长期处于idle状态，说明池子过大
如何用环境变量动态控制，又不踩类型转换坑？
硬编码在 config/autoload/databases.php 里等于放弃运维弹性。但直接用 env('DB_POOL_MAX') 会返回字符串，PHP 弱类型可能让 max_connections 变成字符串 "50"，Hyperf 内部类型校验失败后静默 fallback 到默认值 10，你根本不会收到报错。
正确做法是显式类型转换，并提供合理兜底：
'pool' => [
'enable_pool' => true,
'min_connections' => (int) env('DB_POOL_MIN', 5),
'max_connections' => (int) env('DB_POOL_MAX', 32),
'wait_timeout' => (float) env('DB_POOL_WAIT_TIMEOUT', 3.0),
],
- 务必用
(int)和(float)强转，别信intval()或floatval()——它们对空字符串或非数字返回 0，比默认值还危险 -
.env中不要加引号：DB_POOL_MAX=32✅，DB_POOL_MAX="32"❌（会被当字符串读） - 改完配置后，用
php bin/hyperf.php start启动时观察日志是否输出Database pool enabled for default，否则说明enable_pool未生效
连接池参数和协程池、Worker 数必须联动看
单独调优连接池没意义。Hyperf 的请求链路是：Worker 进程 → 协程 → 连接池。如果 max_coroutine 设为 3000，但 max_connections 只有 20，那最多只有 20 个协程能真正发 SQL，其余 2980 个卡在连接等待队列里——此时 wait_timeout 再小也救不了。
- 推荐比例关系：
max_connections ≥ worker_num × 2（例如worker_num=8，则max_connections≥16） - 若使用异步任务（
task_worker_num > 0），需额外预留连接：每个task_worker最多可能持有一个连接，建议 +5～10 - 上线前必查
swoole_server->stats()中的connection_num和tasking_num，两者持续高于配置值 80%，就得扩容而非加日志
最易被忽略的一点：连接池大小不是静态值。它必须随业务流量峰谷动态响应——比如报表导出任务触发时，临时提升 max_connections，任务结束再缩容。靠人工 reload 不现实，得用事件监听 + JMX 或 Prometheus 指标驱动自动扩缩。
