ThinkPHP项目如何处理数据库连接超时_连接池与长连接设置

在开发ThinkPHP项目时，数据库连接超时，特别是那个经典的 SQLSTATE[HY000] [2006] MySQL server has gone away 错误，几乎是每个开发者都会遇到的“老朋友”。这其实不是ThinkPHP本身的锅，问题出在MySQL的 wait_timeout（默认8小时）和 interactive_timeout 参数上。当连接空闲太久，MySQL会主动断开，而TP默认复用的PDO连接句柄并没有做失效检测，于是报错就来了。

处理这个问题的思路，不是简单地调大MySQL的超时值，而是让TP在执行查询前确认连接是否还“活着”。最直接的办法是在数据库配置中开启 'break_reconnect' => true，这样TP在遇到连接失败时会自动重连一次，适用于单次查询失败的情况。更稳妥的做法是配合 'deploy' => 0（单库模式）和 'params' => [\PDO::ATTR_PERSISTENT => false]，彻底禁用PDO持久连接，避免复用那些已经断开的“僵尸连接”。如果非要使用长连接，就得在每次查询前手动加个 $this->query('SELECT 1') 的心跳探测——但这会带来额外的开销，不太推荐。

ThinkPHP 6/7 是否支持连接池？

答案很明确：官方没提供，得自己动手。TP原生不带连接池，think-swoole 扩展也只是封装了协程MySQL客户端，并没有实现连接复用和调度的逻辑。真要上连接池，就得绕过TP的Db类，直接对接 Swoole\Coroutine\MySQL 或第三方协程池（比如 swoole/co-pool）。

常见的做法是：在Swoole Server启动时初始化一个协程池，把 Swoole\Coroutine\MySQL 实例存进去；业务代码中通过 $pool->get() 获取连接，用完后通过 $pool->put($conn) 归还。这里需要特别注意两点：

• TP的模型和查询构造器（Db::table()）完全无法接入这套机制，只能手写原生SQL配合协程MySQL执行。
• 连接池的 maxIdleTime 必须小于MySQL的 wait_timeout，否则池子里那些“死连接”会直接导致查询失败。

别被 'persistent' => true 的名字骗了

TP配置里的 'persistent' => true 只是透传给了PDO的 PDO::ATTR_PERSISTENT，它依赖PHP-FPM的进程生命周期。每个FPM worker进程会缓存一个连接，进程结束才释放。这根本不是真正意义上的“长连接池”，也不跨进程共享。

这个配置的实际效果很有限：

• 在FPM动态模式下，worker频繁启停，持久连接基本形同虚设。
• 连接数 = 并发请求数 × worker数，很容易打爆MySQL的 max_connections。
• 一旦MySQL重启或网络闪断，这个“持久”连接就会永久卡死，后续所有请求都会挂掉。

生产环境建议始终设为 false，连接复用的事交给数据库中间件（如ProxySQL、MySQL Router）或应用层连接池来处理。

如何验证当前连接是否被复用？

别只盯着TP日志，直接查数据库状态最准：

SHOW STATUS LIKE 'Threads_connected';

在高并发压测时反复执行这句，如果数值持续上涨且不回落，说明连接没被回收，很可能是持久化开关没关，或者没有正确关闭连接。如果数值稳定在5–20这个区间，说明连接复用正常。再结合慢日志里的 Connect 时间戳，就能判断出连接是否真的“长”了。

真正棘手的不是配置开关，而是当你混合使用Db类、原生PDO和Swoole MySQL时，它们各自维护一套连接生命周期。这时候连接行为完全不可预测，最容易出现超时又不报错的静默失败，这才是需要重点关注的。