如何优化ThinkPHP数据库连接池及长连接以应对连接超时问题？

本文共计925个文字，预计阅读时间需要4分钟。

这是最常见现象：

解决思路不是“加长 timeout”，而是让连接在使用前自检是否还活着：

• 在数据库配置中开启 'break_reconnect' => true（TP6.0+），它会在 PDO 报错后自动重连一次
• 更稳妥的做法是配合 'deploy' => 0（单库模式） + 'check_conn' => true（TP6.3+ 新增），后者会在每次获取连接时执行 PDO::getAttribute(PDO::ATTR_SERVER_INFO) 做轻量探测
• 避免在事务中跨长时间操作——beginTransaction() 后如果 sleep(30)，连接大概率已断，后续 commit() 必然失败

TP6 的 connection 配置里要不要设 'persistent' => true

不要。PHP-FPM 下开启长连接（persistent）反而容易引发连接泄漏和状态污染。每个 FPM worker 进程会缓存自己的 PDO 实例，但 ThinkPHP 的连接池管理逻辑并未完全适配持久化连接的生命周期，容易出现：

• 事务未正确 rollback，下个请求复用该连接时读到脏数据
• 字符集、时区等 session 级设置残留，影响后续查询
• MySQL 报 Too many connections，但 SHOW PROCESSLIST 显示大量 Sleep 连接，实际是 FPM 进程没释放

真实高并发场景下，连接池收益远大于持久化连接——用 'pool_size' => 20（需配合 'deploy' => 1 或独立配置多个节点）更可控。

立即学习“PHP免费学习笔记（深入）”；

手动管理连接池：什么时候该调 Db::close()？

绝大多数情况不用主动关。ThinkPHP 在 Request 生命周期结束时会自动释放连接（包括连接池归还）。但以下两个场景必须干预：

• CLI 命令中循环处理大批量数据（如每批 1000 条），不关连接会导致连接数线性增长，最终触发 MySQL 限制——应在每批处理完后调 Db::close()
• 使用了 Db::connect() 手动指定配置创建连接，且该连接仅用于临时任务（如对接第三方 DB），务必在任务结束后显式调 $conn->close()，否则它不会进默认连接池，也不会被自动回收

注意：Db::close() 关的是当前默认连接；若用了 Db::name('user')->connect('other')，要先切回再关，或直接保存连接对象调 close()。

wait_timeout 和 interactive_timeout 该调哪个？

调 wait_timeout 就够了。ThinkPHP 使用的 MySQL 连接默认是非交互式（CLIENT_INTERACTIVE 未启用），所以生效的是 wait_timeout（默认 28800 秒 = 8 小时）。

但别盲目调大。设成 24 小时看似保险，实际会让失效连接滞留更久，连接池命中率下降，还可能掩盖应用层连接未释放的问题。合理值是：

• Web 请求场景：300～600 秒（5～10 分钟），匹配 PHP max_execution_time 和 Nginx proxy_read_timeout
• CLI 场景：按任务最长耗时 + 60 秒冗余，比如导出脚本预计跑 1200 秒，就设 wait_timeout = 1260

改完记得重启 MySQL，且要确认应用侧没有用 mysql_set_charset 类旧函数绕过 PDO，否则配置可能不生效。