PHP无原生连接池，所谓“连接池”实为持久连接、ProxySQL代理或Swoole协程池三种替代方案；持久连接易致数据污染，ProxySQL是生产级推荐方案，Swoole协程池仅适用于常驻内存场景。
PHP本身没有原生连接池，别被“连接池”字眼误导
PHP是无状态、短生命周期的脚本语言，每次请求启动新进程或协程，PDO 或 mysqli 都不提供跨请求的连接池管理能力。所谓“配置连接池”，实际是三种不同层级的替代方案：持久连接（per-request 复用）、中间件代理（如 ProxySQL）、或协程框架内建池（如 Swoole）。直接在 php.ini 里搜 connection_pool 是找不到的——它根本不存在。
启用持久连接（pconnect）是最常用但最易出错的方式
持久连接不是连接池，只是把连接缓存在 PHP 进程内，供后续同配置请求复用。但它有明确限制和副作用：
-
mysqli中需设置'pconnect' => TRUE（CodeIgniter）或在 DSN 中加&pconnect=1（旧版 mysqli_connect） -
PDO必须在构造时传入[PDO::ATTR_PERSISTENT => true]；用setAttribute()后设无效 - 事务未提交、临时表未清理、会话变量残留，都会污染下一次复用——这是线上偶发“数据错乱”的常见原因
- Apache 的 prefork 模式下，每个子进程维护独立池，
mysqli.max_persistent限制的是单进程上限，不是全局总数 - 若数据库重启或网络中断，PHP 不会自动剔除失效连接，下次复用时才报
MySQL server has gone away
用 ProxySQL 做透明代理才是生产级“连接池”正解
当需要真正控制最大连接数、读写分离、故障自动切换时，必须把连接池逻辑下沉到中间件层。ProxySQL 是目前最轻量、兼容性最好的选择：
- PHP 应用完全无感：只需把
host从localhost:3306改成localhost:6033（ProxySQL 默认监听端口） - 在 ProxySQL 中执行
INSERT INTO mysql_servers添加后端 MySQL 实例，并设置max_connections和connect_timeout_server - 关键配置项
mysql-native_password必须开启，否则 PHP 8.2+ 的默认认证方式会握手失败 - 不要依赖
PDO::ATTR_PERSISTENT与 ProxySQL 共存——它只会让 PHP 层多一层无意义的缓存，反而增加连接泄漏风险 - 监控看
stats_mysql_connection_pool表，重点关注ConnUsed和ConnFree，避免ConnActive长期满载
Swoole 协程 + Swoole\Coroutine\MySQL 是唯一能做真连接池的 PHP 方案
仅适用于常驻内存模式（如 Swoole HTTP Server），且必须关闭 opcache.enable_cli=0 并启用 swoole.use_shortname=Off 避免函数名冲突：
立即学习“PHP免费学习笔记（深入）”；
- 不能直接 new
PDO或mysqli，必须用Swoole\Coroutine\MySQL客户端 - 连接池需手动实现：
Channel存连接对象，go协程中pop获取，push归还，超时未归还会触发Channel::close() - 注意
max_idle_time参数：连接空闲超过该秒数会被自动销毁，防止长连接因数据库侧 timeout 被强制断开 - 若混用同步阻塞调用（如
file_get_contents），协程池会卡死——所有 I/O 必须走Swoole\Coroutine系列 API
真正难的不是配置，而是判断该用哪一层：普通 FPM 项目只配 PDO::ATTR_PERSISTENT + ProxySQL；Swoole 服务才能上协程池；而任何试图用 pcntl_fork 自己手撸进程级池的，基本等于给自己埋雷。
