webman数据库连接池需精准配置：总连接数=worker_num×max_connections，min_connections设1–2预热，max_connections≤mysql总限÷worker数，wait_timeout建议3秒；禁用new pdo()直连，须走db门面；连接池不解决sql性能问题，需同步优化索引、事务和批量操作。
Webman 的数据库连接池不是“开了就行”，不配对参数或混用模式，反而会压垮 MySQL。 它必须和常驻进程模型匹配，否则 min_connections 白设、max_connections 反成累赘、wait_timeout 直接引发超时雪崩。
config/database.php 的 pool 配置项怎么填才不翻车
Webman 每个 Worker 进程独立持有连接池，总连接数 = worker_num × max_connections。若你启了 12 个 Worker，max_connections 设 20，MySQL 就得扛住 240 个长连接——这已经超过多数云数据库默认上限（如阿里云 RDS MySQL 默认 100）。
-
min_connections建议设为1或2：冷启动时预热连接，避免首请求卡在建连；设太高会导致空闲连接长期占着端口和内存 -
max_connections必须 ≤ MySQL 的max_connections÷ Worker 数：比如 MySQL 允许 200 连接、你开了 8 个 Worker，这里最多填25，留点余量更稳妥 -
wait_timeout推荐3秒：连接空闲超时后自动回收，防止连接池里塞满“假活”连接；设成0或过大，容易触发 MySQL 的wait_timeout主动断连，后续请求拿到失效连接直接报PDOException: SQLSTATE[HY000] [2006] MySQL server has gone away
为什么 new PDO() 或 DB::connection() 在控制器里调用是危险操作
Webman 是常驻内存模型，但 PDO 实例不可跨进程序列化，也不支持复用。每次在控制器里 new PDO() 或手动调 DB::connection()，等于绕过连接池，每个请求新建一个 TCP 连接 —— 不仅耗尽 MySQL 连接数，还会快速堆积 TIME_WAIT 状态，最终出现 Can't create TCP socket 或 Too many connections 错误。
- 正确做法只有一条：所有数据库操作走框架封装的
DB门面或 Eloquent Model，它底层自动从连接池取连接 - 绝对不要在
onWorkerStart里new PDO并赋值给全局变量：多 Worker 下会引发连接被多个进程误用，轻则查询错乱，重则连接句柄被重复 close 导致崩溃 - 如果你用了第三方 ORM（如 Doctrine），确认它支持连接池代理；否则仍会退化为直连模式
连接池生效但查询还是慢？检查这三处隐性瓶颈
连接池解决的是“建连开销”，不是“SQL 性能”。即使池配置完美，以下问题照样拖垮吞吐：
- 没加索引的
WHERE字段（比如查mobile却没建索引）：执行计划走全表扫描，100 万行数据下单次查询就 300ms+，连接池再快也救不了 - 事务里混用读写：比如在大事务中先
UPDATE再SELECT ... FOR UPDATE，锁等待时间叠加，连接池里的连接会被长时间 hold 住，新请求排队等死 - PHP 层批量操作没走
insertAll()或upsert()：用循环insert()100 条，等于发 100 次网络请求 + 100 次连接池调度，实测比单条INSERT ... VALUES (...), (...), (...)慢 5–8 倍
连接池不是银弹。它只管“连接怎么来”，不管“SQL 怎么写”“索引怎么建”“事务怎么分”。很多人调完 pool 参数就以为高并发稳了，结果压测一跑，慢查询日志里全是未命中索引的 SELECT —— 那不是连接池没起作用，是你把“交通管制”当成了“修路”。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
