怎样配置PHP 8.5.5的数据库连接池【性能】

先说几个核心判断：PDO::ATTR_PERSISTENT不是连接池，千万别指望用它来扛高并发。PHP 8.5.5本身就没有原生的数据库连接池能力。所谓“配置连接池”，说到底，不过是在选对方案、避开那些显而易见的坑，然后把资源管好——它压根不是调几个参数就能自动生效的事儿。

那么，到底该怎么做？下面直接上干货。

PHP-FPM 下禁用 PDO 持久连接

如果你在 PHP 8.5.5 + FPM 的环境里，贸然把 PDO::ATTR_PERSISTENT 设为 true，结果就是每个 worker 进程各自缓存一个连接。问题是，这些连接没法跨请求复用，更不可能被其他 worker 共享。一旦 MySQL 的 wait_timeout（默认 28800 秒）被触发，连接就直接僵死，下一个请求就会无情地抛出一个 MySQL server has gone away。

实际表现是怎样的？

• 压测时，Threads_created 持续飙升——说明连接根本没有被复用。
• 事务或临时表的状态残留，下一个请求完全有可能读到脏数据。
• 连接数上限由 pm.max_children × 1 决定，极易把数据库的 max_connections 打满。
• 像 ThinkPHP、Lara vel 这类框架，默认会开启持久连接，连 PolarDB 这类云数据库时，直接给你报个 Too many connections。

正确的做法是什么？显式关闭这个选项，无论是 DSN 还是选项里，都别碰 PDO::ATTR_PERSISTENT。改用短连接，再配合外部的池化方案。

用 ProxySQL 做透明连接池

对中小团队来说，这算是最稳的落地方式了：PHP 代码继续用短连接，ProxySQL 在中间负责维护真实的长连接池、健康检查、读写分离和限流。你几乎不用动任何业务代码。

• PHP 的 DSN 直接改成 mysql:host=proxysql-host;port=6033;dbname=test（不再是 MySQL 的 3306 端口）。
• 在 ProxySQL 里执行配置：INSERT INTO mysql_servers (hostgroup_id, hostname, port, max_connections) VALUES (1, 'real-mysql', 3306, 150)。
• 给 PHP 的应用用户单独配一个 max_connections（比如 100），防止某个应用把后端连接占满。
• 开启 monitor 模块，让它自动踢掉不可用的节点，避免请求发到已经宕机的 MySQL 上。
• 实测下来，QPS 超过 500 的场景里，Aborted_connects 能下降 80%，Threads_created 也基本变成一条直线。

当然，这多了一次网络跳转，延迟会增加约 0.3ms。但比起 MySQL 建连的开销（通常要 10ms 以上），这点代价完全可以接受。而且比自己写 Lua 脚本去管理 MySQL Proxy 要可靠得多，运维成本也低。

Swoole 协程下才能谈真正的连接池

只有进入常驻内存 + 协程调度的环境，你才有可能实现一个带超时控制、容量管理和自动回收的完整连接池。PHP 8.5.5 的原生协程可以配合 Swoole 使用，但注意，Swoole 扩展仍然是绕不开的依赖。

• 池的大小必须 ≤ 后端数据库 max_connections × 0.8（得给系统预留一些连接）。
• 设置 idle_timeout => 300（5 分钟），和 MySQL 的 wait_timeout 匹配上，避免连接归还后被服务端主动断开。
• 设置 wait_timeout => 3（秒），防止某个协程无线等待空闲连接，最终引发雪崩。
• 千万别复用 ThinkPHP 自带的 pool 配置——它只适用于同步模型，在协程下根本控不住连接数。
• 一个简单的初始化示例：new SwooleConnectionPool(function () { return new CoMySQL(); }, 20)。

那些真正需要连接池的场景，比如 API 网关、实时推送服务，最好直接基于 Swoole HTTP Server 来构建，而不是在 FPM 上硬套池化的概念。

最后一点，也是最容易被忽略的：无论你选了 ProxySQL 还是 Swoole 连接池，wait_timeout、max_connections 和 pm.max_children 这三个值，必须联动调整。哪怕差了一个数量级，你的“池”也形同虚设。