php无内置连接池，真正可行方案只有两类：一是使用swoole扩展实现协程连接池；二是采用proxysql等代理层方案。其他如redis模拟或static变量均无效。
PHP 本身没有内置连接池机制
PHP 的传统运行模型（如 Apache + mod_php 或 PHP-FPM）是无状态、请求结束即销毁资源的，mysqli 或 PDO 建立的数据库连接在脚本执行完后自动关闭。这意味着：你无法像 Java 的 HikariCP 或 Go 的 sql.DB 那样，在进程生命周期内复用一组常驻连接。
所以，所谓“PHP 连接池”，本质是绕过 PHP 自身限制，借助外部服务或特殊运行时实现的方案。直接在普通 PHP-FPM 环境里写个“连接池类”基本无效——每个请求都实例化新对象，连接仍会反复创建/销毁。
真正可行的连接池方案只有两类
目前生产环境能落地的，只有以下两种路径，其余多为概念演示或伪实现：
-
使用 Swoole 扩展（推荐）：Swoole 是常驻内存的协程服务器，可在 Worker 进程启动时初始化连接池（如
Swoole\Coroutine\MySQL或第三方库co\mysql/spiral/database），连接在协程间复用且不阻塞。示例关键点：
– 启动时用go协程预创建连接
– 使用Pool类封装获取/归还逻辑（如hyperf/pool提供的ConnectionPool）
– 注意连接超时、心跳检测（ping()）和最大空闲时间配置，否则连接会因 MySQLwait_timeout中断 - 代理层方案（如 ProxySQL 或 MaxScale）：把连接池逻辑下沉到数据库前端代理，PHP 应用仍走短连接，但代理层维护真实长连接池并做负载、熔断、读写分离。优势是零侵入 PHP 代码，兼容所有框架；缺点是运维多一层组件，需额外监控代理健康状态
为什么不要自己用 Redis 或文件模拟连接池
常见误区是用 Redis 存序列化的 PDO 对象，或用 flock + 文件存连接句柄。这些做法问题明确：
立即学习“PHP免费学习笔记（深入）”；
- PDO / mysqli 资源句柄不能序列化，
serialize($pdo)直接报错Serialization of 'PDO' is not allowed - 即使强行保存连接参数再重连，仍没解决 TCP 握手、鉴权、初始化开销，性能提升极有限
- 并发下容易出现连接泄漏（忘记归还）、超时未清理、跨进程共享失效等问题
- PHP-FPM 子进程各自独立内存空间，
static变量或全局数组无法跨请求共享连接
高并发下更值得优先做的其实是连接优化
比起强推“连接池”，先确认并落实这些基础项，往往收益更大：
- 检查 MySQL 的
max_connections和wait_timeout是否合理（如设为 300 秒，配合 PHP 层mysqli_options(MYSQLI_OPT_CONNECT_TIMEOUT, 3)） - 用
PDO::ATTR_PERSISTENT => true开启持久连接（仅限 PHP-FPM 模式有效，且要注意连接状态残留风险） - 减少不必要的连接：合并查询、用事务批量操作、避免在循环里反复
new PDO() - 加监控：通过
SHOW STATUS LIKE 'Threads_connected'实时观察连接数峰值，比盲目上池子更有依据
真正需要连接池的场景，通常已切换到 Swoole 或 RoadRunner 这类常驻进程模型；还在用 FPM 却执着于“PHP 连接池”，大概率是在解决一个不存在的问题。
