PHP-FPM模式下PDO::ATTR_PERSISTENT仅实现单进程内连接复用，非真正连接池；连接绑定worker生命周期，无法跨请求/进程共享，易僵死且引发状态残留；ProxySQL或Swoole协程才是有效方案。
PHP-FPM 环境下没有真正的连接池
直接说结论：PHP-FPM 模式中，PDO::ATTR_PERSISTENT => true 不是连接池，只是进程内连接复用。每个 FPM worker 启动后会缓存一个连接，但该连接生命周期绑定于 worker，无法跨请求共享，也无法被其他 worker 复用。一旦 worker 被回收（如达到 pm.max_requests），连接就销毁；若 MySQL 侧先断开（如 wait_timeout 触发），这个“持久连接”可能僵死，后续请求会报 MySQL server has gone away。
常见错误现象包括：
- 压测时
Threads_created持续上升，说明连接频繁重建 - 日志中反复出现
SQLSTATE[HY000] [2006] MySQL server has gone away - 开启持久连接后，事务或临时表状态意外残留，影响下一个请求
所以别指望靠 PDO::ATTR_PERSISTENT 解决高并发连接瓶颈。它最多省掉单次请求内的 TCP 握手，但解决不了连接数打满、资源不可控的问题。
ProxySQL 是中小团队最稳的“伪池化”方案
不改代码、不换框架、不碰协程，也能落地连接池效果——用 ProxySQL 做中间层。它对 PHP 完全透明：你仍用短连接连 ProxySQL，它自己维护与后端 MySQL 的长连接池，并支持读写分离、自动故障转移、连接数限制和慢查询拦截。
立即学习“PHP免费学习笔记（深入）”；
关键配置点：
- 在 ProxySQL 的
mysql_servers表中设置max_connections，控制每个后端实例最大连接数 - 在
mysql_users表中为 PHP 用户配max_connections和default_hostgroup - 启用
monitor模块，让 ProxySQL 主动检测 MySQL 健康状态，避免把请求发给宕机节点 - PHP DSN 改为连
host=proxysql-host;port=6033，而非直连 MySQL 端口
性能影响明显：实测 QPS 500+ 场景下，MySQL Aborted_connects 下降 80%，Threads_created 趋于平稳。缺点是多一层网络跳转（延迟增加 0.2–0.5ms），但远小于建连开销。
Swoole 协程下才谈得上“真连接池”
只有在常驻内存、协程调度的环境里，比如 Swoole HTTP Server 或 Task Worker 中，才能用 Swoole\Coroutine\MySQL 或 Pool 类实现带超时、最大空闲/活跃数、健康检查的完整连接池。
典型用法：
- 初始化时创建
Pool实例，minIdle设为 4，maxActive设为 32，maxWaitTime控制获取连接最长等待 - 每次数据库操作前调用
$pool->get()，用完立刻$pool->put($conn)，不能依赖析构函数 - 必须在
get()后做简单心跳（如$conn->query('SELECT 1')），否则空闲连接可能被 MySQL 主动断开 - 避免在协程外复用同一个
$conn，协程切换后连接上下文不安全
注意：Swoole 4.8+ 才默认启用 mysqlnd 连接池支持；低于此版本即使写了 Pool，底层仍是每次新建连接。
自己写 Pool 类基本等于白忙活
网上流传的 PHP 原生 DatabasePool 类（含 $pool 数组 + createConnection()）在 FPM 下毫无意义：每次请求都 new 一个新 Pool 实例，里面的连接数组根本活不过当前请求。即使配合 APCu 或 Redis 存连接句柄，也会因 PHP 的进程隔离模型导致连接资源无法真正共享，反而引入锁竞争和序列化开销。
如果你坚持要“自己实现”，唯一可行路径是：
- 仅用于 CLI 常驻进程（如队列消费者）
- 连接对象必须是可序列化的（PDO 不行，需用 mysqli 或自定义封装）
- 必须自己实现连接有效性检测、超时淘汰、异常重连逻辑
- 放弃“跨进程共享”，只做单进程内连接复用
实际项目中，95% 的这类轮子最终都被 ProxySQL 或 Swoole 替代。真正容易被忽略的是：连接池不是性能万能药——如果单个 SQL 平均耗时 800ms，加池子只会让线程堵得更密，先优化 SQL 和索引，再谈池化。
