PHP无内置连接池，需用PDO或mysqli持久连接模拟：DSN加p:前缀或设PDO::ATTR_PERSISTENT=true，但须防状态残留、连接失效及泄露，优先优化SQL而非过度设计连接池。
PHP 本身没有内置连接池，得靠应用层模拟
PHP-FPM 是进程/线程模型，每个请求独占一个 Worker，mysqli 或 PDO 连接在脚本结束时自动关闭。所谓“连接池”，其实是用持久连接 + 连接复用逻辑来逼近效果，不是像 Java 那样有独立的池管理器。
真正起作用的是 MySQL 的 mysqlnd 持久连接机制，但默认不开启，且容易被误用：
-
mysqli_pconnect()已废弃，不要用 - 用
new mysqli($host, $user, $pass, $db, $port, $socket)时传MYSQLI_CLIENT_INTERACTIVE无用；持久性由连接字符串前缀控制 - 正确方式是：在 DSN 中加
p:前缀（如"p:127.0.0.1"），或 PDO 构造时设PDO::ATTR_PERSISTENT => true
用 PDO 持久连接要注意连接泄露和状态残留
开启 PDO::ATTR_PERSISTENT 后，连接不会随脚本结束而销毁，而是放回连接缓存——但这个“缓存”不清理会话状态。比如上一个请求执行了 SET NAMES utf8mb4 或开启了事务，下一个请求可能直接继承这些状态，导致乱码或锁表。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 每次获取连接后，显式重置关键会话变量：
$pdo->exec("SET NAMES utf8mb4");、$pdo->exec("SET autocommit = 1"); - 避免在持久连接中长期持有未提交事务；
try/catch里务必$pdo->rollBack()或$pdo->commit() - 不要依赖
__destruct关闭连接——持久连接不能关，也不该关 - 连接数上限由 MySQL 的
max_connections和 PHP-FPM 的pm.max_children共同决定，别盲目调高
简单复用逻辑：单例 + 连接检测比每次都 new 更可靠
很多人以为“new 一次存全局”就是池，其实漏掉了连接失效问题。MySQL 连接可能因超时（wait_timeout）、网络中断、服务重启而断开，下次直接用就会抛 PDOException：“MySQL server has gone away”。
基础防护做法：
- 封装一个
getDb()函数，内部检查连接是否有效：$pdo->getAttribute(PDO::ATTR_CONNECTION_STATUS)不可靠，改用轻量查询：$pdo->query("SELECT 1")->fetchColumn() - 捕获异常后，unset 旧实例，重新创建连接（注意：不是 reconnect，是重建）
- 不要在构造函数里做连接，把连接延迟到第一次 query 前
- 示例片段：
if (!$this->pdo || !$this->ping()) { $this->pdo = new PDO($dsn, $user, $pass, [PDO::ATTR_PERSISTENT => true]); }
连接池意义有限，优先优化查询和索引
PHP 场景下，连接建立耗时通常远小于慢查询本身。压测会发现：当 QPS 上千时，瓶颈几乎总在 SQL 执行时间、锁竞争或网络往返，而不是 TCP 握手。强行搞复杂连接池（如用 Redis 管理连接句柄、fork 子进程维护池）反而增加维护成本和内存泄漏风险。
更实际的路径是：
- 确认 MySQL 的
wait_timeout大于 PHP-FPM 的request_terminate_timeout，避免连接被服务端先杀 - 用
mysqlnd而非libmysqlclient，前者对持久连接支持更好 - 监控
Threads_connected和Aborted_connects，判断是否真存在连接风暴 - 如果真遇到连接数打满，先看是不是没 close statement、没 unset 结果集、或循环里反复 new PDO
连接复用能省下的那几十毫秒，在一条 200ms 的慢查询面前，基本可以忽略。
