ThinkPHP 没有真正的数据库连接池，因其基于 PHP-FPM 短连接模型，连接随请求结束自动释放；所谓“连接池监控”实为误用概念，应关注连接复用状态、异常残留、超时堆积及配置合理性。
ThinkPHP 本身不提供数据库连接池功能，也没有内置的连接池监控机制——它用的是 PHP 原生 PDO 或 mysqli 的短连接模型，每次请求结束自动释放连接。所谓“连接池监控”，实际是误用概念，真正该关注的是连接复用状态、异常连接残留、超时堆积和配置合理性。
为什么 ThinkPHP 没有真正的连接池
PHP 是无状态的脚本语言，FPM 进程处理完请求即销毁资源；PDO 默认不保持长连接，除非显式设置 PDO::ATTR_PERSISTENT => true（即持久连接），但这也只是进程内复用，并非跨进程/线程的连接池。TP 的 Db 类和 Connection 类全程基于单次请求生命周期设计，不会主动维护连接队列或健康检查。
- 开启
'persistent' => true后，连接由 PHP-FPM worker 进程缓存，重启进程才清空 - 持久连接无法自动剔除断连、超时或被服务端强制关闭的连接
- 高并发下可能因连接数爆满触发 MySQL 的
max_connections限制，报错SQLSTATE[HY000] [1040] Too many connections - TP 日志里看不到连接获取/释放的详细链路，需靠 MySQL 自身视图定位
如何观察当前数据库连接真实状态
不能依赖 TP 日志，得直接查 MySQL 服务端。最有效的方式是登录数据库执行以下语句：
SHOW PROCESSLIST;
重点关注 State 列为 Sleep 且 Time 超过 60 秒的连接——这大概率是 TP 请求结束后未正确关闭的残留连接（常见于事务未提交/回滚、异常中断或手动调用了 Db::connect() 但忘了 ->close()）。
立即学习“PHP免费学习笔记（深入）”；
- 用
SELECT * FROM information_schema.PROCESSLIST WHERE USER = 'your_db_user';筛选应用用户连接 - 配合
SHOW VARIABLES LIKE 'wait_timeout';确认服务端空闲超时值，TP 的'params' => [\PDO::ATTR_TIMEOUT => 5]只控制查询超时，不影响连接空闲释放 - 若使用 Swoole 或 Hyperf 等常驻内存框架，才需要引入
robfig/circus或自研连接管理器，TP 不适用
TP 配置中影响连接行为的关键参数
虽然没连接池，但几个配置项会显著改变连接表现：
-
'deploy' => 0：单库模式；设为1或2启用读写分离后，每个节点独立建连，连接数翻倍，务必检查从库max_connections -
'debug' => true：开启后每次查询都会触发PDO::getAttribute(PDO::ATTR_SERVER_VERSION)，额外建立一次连接（仅开发环境明显） -
'params' => [PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION]：推荐始终启用，否则连接失败时静默忽略，导致后续操作用到无效连接对象 -
'break_reconnect' => true：当主库断开时是否尝试重连，默认 false；设为 true 可减少报错，但掩盖了网络稳定性问题
线上应监控哪些指标而非“连接池”
与其纠结不存在的连接池，不如盯住这些可采集、可告警的真实指标：
- MySQL 的
Threads_connected（当前连接数），对比max_connections，阈值建议设为 80% - TP 应用日志中出现
SQLSTATE[HY000] [2002]（连接拒绝）或[2013]（连接丢失）的频次 - 慢查询日志中
Rows_examined极高但返回行数为 0 的 SQL——这类查询常持连时间长，间接拖慢连接周转 - PHP-FPM 的
slowlog中出现mysqli::query或PDO::prepare卡顿，说明连接层已成瓶颈
复杂点在于：TP 把连接抽象得太深，你很难在不侵入 think\db\Connection 类的前提下打点统计。如果真要监控连接获取耗时，唯一稳妥方式是在自定义数据库中间件里包裹 Db::connect() 调用，并记录 microtime(true) 差值——但要注意，这个值反映的是连接初始化开销，不是“从池里取连接”的时间。
