根本原因是thinkphp默认短连接+每次请求新建连接，且未正确处理事务提交、异常回滚或cli长任务释放，导致连接泄漏；需配置max_active限流、用try-catch兜住事务、cli下主动close。
为什么 max_connections 设得再大也挡不住连接耗尽
根本原因不是 MySQL 限制太严，而是 ThinkPHP 默认用的是短连接 + 每次请求新建连接。哪怕你把 max_connections 调到 1000，只要并发请求里有慢查询、事务没提交、或代码里 Db::query() 后忘了释放，连接就会卡在 sleep 状态不归还，池子很快被占满。
实操建议：
- 先查 MySQL 实时连接：执行
SHOW PROCESSLIST，重点关注状态为Sleep且Time超过 30 秒的连接，它们大概率是没被回收的 ThinkPHP 连接 - 确认是否启用了连接池：ThinkPHP 6.1+ 才原生支持连接池，低版本（如 TP5.1）压根没有
pool配置项，强行写进去无效 - 检查
database.php中是否误配了'break_reconnect' => true—— 这个选项会让失败连接直接丢弃而不归还池子，加剧泄漏
pool 配置项里哪些参数真起作用，哪些只是摆设
ThinkPHP 的连接池不是“开箱即用”的智能池，它只控制连接的创建和复用逻辑，不自动 kill 掉空闲太久的连接。真正影响连接数上限的是三个硬性参数：
-
'min_idle' => 5：启动时预建 5 个空闲连接，避免首请求等待建连；但设太高会一上来就占满 MySQL 的wait_timeout限额 -
'max_active' => 20：池中最多允许 20 个活跃连接（正在执行 SQL 的），超过则阻塞或报错；这是防止打爆数据库的核心闸门 -
'max_wait_time' => 3000：获取连接超时毫秒数，设太小（如 100）会导致高并发下大量Wait timeout for connection报错
注意：'timeout' 是单条 SQL 执行超时，和连接池无关；'idle_timeout' 在 TP6.1 中实际未生效，别依赖它自动清理空闲连接。
事务中忘记 commit() 或 rollback() 会怎样
这是最隐蔽的连接耗尽诱因。一旦开启事务，ThinkPHP 会从池中取出一个连接并长期持有，直到显式提交或回滚。如果中间抛异常没被捕获，或逻辑分支漏写了 $db->commit()，该连接就永远卡在 Transaction 状态，既不执行新 SQL，也不归还池子。
实操建议：
- 所有事务必须用
try...catch包裹，catch块里强制$db->rollback() - 避免在事务里调用外部 HTTP 请求或 sleep，这些操作会让连接空等，快速挤占池子
- 开发期打开
'debug' => true，观察日志里是否有长时间未结束的START TRANSACTION记录
长连接场景下必须手动调 Db::close() 吗
不需要，也不应该手动调。ThinkPHP 的连接池设计是“请求结束自动归还”，前提是没发生未捕获异常、没卡死在事务里、也没在 CLI 模式下长期运行脚本。
唯一要主动关连接的场景是 CLI 长任务（比如队列消费者）：
- 每次处理完一条消息后，调一次
Db::close()，否则连接会一直挂着，几小时后全部变成sleep - 不要在循环里反复
Db::connect()，而应复用同一个实例，再通过Db::close()主动释放 - CLI 模式下务必设置
'deploy' => 0（禁用读写分离），否则主从连接可能错乱归还
连接池不是万能的，它只解决“复用”，不解决“泄漏”。真正决定连接数是否爆炸的，永远是那几行没写完的 commit、没兜住的异常、和没意识到自己在 CLI 下跑了三天的定时任务。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
