mysql连接数爆满时不应盲目改用mysql_pconnect（php 7.0+已移除，易致泄漏），而应先排查慢查询、未关闭连接、ddl锁等问题，合理配置max_connections与fpm参数，并在swoole等常驻模型中才考虑连接池。
连接数爆满时，mysql_pconnect 为什么不能直接开
ThinkPHP 默认用的是 PHP 原生 PDO 或 mysqli 短连接，每请求一次就新建、断开一次。有人看到连接数高，第一反应是改成 mysql_pconnect——但这个函数在 PHP 7.0+ 已被移除，且即使旧版本启用，也常导致连接泄漏、状态残留（比如事务未提交、临时表未清理），反而让连接堆积更严重。
真正该做的是：确认是否真需要持久化，还是先压根没关连接。
-
Db::close()在手动操作后必须显式调用，尤其在长循环或命令行任务里，否则连接不会释放 - 配置中
'break_reconnect' => true可防止因单次失败导致整个连接池卡死，但需配合重试逻辑 - 如果用的是
mysqli驱动，'pconnect' => true是有效配置项；但PDO的PDO::ATTR_PERSISTENT => true在 ThinkPHP 中需通过params手动传入，不是靠开关控制
连接池不是 ThinkPHP 原生能力，得靠中间件或代理层
ThinkPHP 本身没有连接池实现，所谓“连接池”在 TP 场景下通常指两种东西：一种是数据库代理（如 ProxySQL、MySQL Router），另一种是应用层复用连接对象（如 Swoole 协程下的 Co\MySQL）。别指望改个配置就能自动池化。
如果你跑在 FPM 下，每个请求都是独立进程，连接池意义不大；只有在 Swoole 或 Hyperf 这类常驻内存模型中，才值得引入连接池管理。
- 使用
swoole_mysql或hyperf/database时，连接由协程上下文维护，yield $db->query(...)后连接会自动归还池中 - FPM 模式下强行模拟池化（比如全局静态保存
$pdo）会导致并发错乱，因为 MySQL 连接不是线程安全的 - ProxySQL 配置里
mysql-pooling=true开启后，需注意max_connections和后端真实 MySQL 的max_connections要匹配，否则代理自己先扛不住
查连接来源：SHOW PROCESSLIST 和慢日志必须一起看
连接数高不等于性能差，可能是大量空闲连接（Command: Sleep），也可能是慢查询堵住连接没释放。光看总数没用，得定位是哪类连接占着不走。
执行 SHOW PROCESSLIST 时重点关注 Time 列大于 60 秒的记录，再结合 Info 字段看 SQL 是否合理；同时打开 MySQL 的 slow_query_log，设置 long_query_time = 1，捕获所有超 1 秒的查询。
- ThinkPHP 日志里的
[ SQL ]行只记录执行语句，不带执行耗时，容易误判；务必以 MySQL 原生日志为准 - TP 的
trace开关开启后会在页面底部显示查询列表，但仅限当前请求，无法反映全局连接状态 - 有些连接卡在
Waiting for table metadata lock，说明有 DDL 操作（如ALTER TABLE）没完成，和应用代码无关，得查 DBA 操作记录
连接数阈值设太低，反而引发雪崩
MySQL 的 max_connections 不建议盲目调高，但设得太低（比如默认 151）在并发稍高时就会直接拒绝新连接，报错 Too many connections。这时应用层若没做降级（比如缓存兜底、队列延迟），就会连锁崩溃。
更危险的是：某些云数据库把连接数当计费指标，盲目扩大会多花钱；而本地开发环境设太高，上线后才发现配置没同步，又会突然报错。
- 线上建议按峰值 QPS × 平均响应时间 × 2 来预估，比如 100 QPS × 0.2s × 2 ≈ 40 个活跃连接，再加 30% 余量，设为 60 即可
- TP 配置中的
'deploy' => 1（读写分离）会额外增加连接数，主库 + 从库各算一套，别漏算 - 使用
php-fpm时，pm.max_children应 ≤ MySQLmax_connections/ 2，否则 PHP 进程数超过可用连接数，必然排队等待
连接数问题从来不是单点配置能解决的，它横跨 PHP 运行模式、框架使用方式、MySQL 参数、代理层策略四层。改一个地方前，先搞清当前瓶颈在哪一层——不然调来调去，只是把压力从连接数转移到 CPU 或磁盘 IO 上。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
