ThinkPHP数据库配置中的连接数限制：max_user_connections报错的解决方案

先说结论：“max_user_connections”报错说白了就是MySQL不让你连了——当前用户的并发连接数已经撑满了服务端的上限。这个上限在云虚拟主机上通常只有80，看起来不高，但一不留神就撞上去。

这个报错跟ThinkPHP配置本身没关系，问题出在MySQL拒绝了新连接。要解决它，得从连接的生命周期管理和MySQL用户级限制两头下手，少一个都不行。

查清楚是哪个用户被限死了

ThinkPHP默认用配置文件里的username连接数据库，而max_user_connections是按MySQL用户粒度来限制的。别急着翻代码，先确认是不是这个用户真的撞上了上限：

• 登录MySQL，跑一下 SHOW VARIABLES LIKE 'max_user_connections'; —— 先看全局默认值，0表示不限
• 再查具体用户：SELECT User, Host, max_user_connections FROM mysql.user WHERE User = 'your_db_user';
• 最后看看当前活跃连接：SHOW PROCESSLIST;，过滤出User列是你的用户名的行，数一数有多少条处于Sleep或Query状态

如果查出来max_user_connections是80，而PROCESSLIST里同一用户的连接数已经达到或超过80，那就坐实了——就是它卡住的。

ThinkPHP 层必须关掉持久连接

TP5/6默认不会开启持久连接，但一旦在数据库配置里误加了 PDO::ATTR_PERSISTENT => true，或者框架扩展、中间件、命令行脚本里手动启用了，连接就会长期滞留不释放。尤其在PHP-FPM子进程复用场景下，一个连接能“挂尸”几分钟甚至更久。

• 检查 config/database.php 中的 params 数组，确保里面没有 PDO::ATTR_PERSISTENT => true
• CLI场景（比如定时任务）最容易漏关：每次执行完都要显式断开，命令结束前加 $pdo = null; 或 Db::close();
• 避免在循环中反复调用 Db::connect()，改用单例复用：$db = Db::connect('default');，并在作用域结束前释放引用

MySQL 侧不能只调 max_connections，得动 max_user_connections

云虚拟主机（比如阿里云、腾讯云的共享型）通常不允许修改全局的max_connections，但允许对单个用户调整max_user_connections——前提是你的账号有GRANT OPTION权限。本地环境或ECS/RDS就可以直接操作：

• 临时生效（重启失效）：SET GLOBAL max_user_connections = 200;（影响所有用户）
• 仅限当前用户：ALTER USER 'your_db_user'@'%' WITH MAX_USER_CONNECTIONS 200;
• 永久生效需要写入MySQL配置文件（my.cnf的[mysqld]段）：max_user_connections = 200，然后重启服务
• 注意：别设太高，每个连接大约占用256KB到1MB内存。如果用户实际并发请求远低于50，设置成100就够用了

别忽略 wait_timeout 和连接泄漏的叠加效应

很多“max_user_connections超限”其实是假象——真实原因是连接没释放，再加上wait_timeout设得太长，导致大量Sleep连接堆积，把名额给占满了。比如云RDS经常把wait_timeout设为300秒，而ThinkPHP某段代码异常后跳过了Db::close()，连接就这么挂着不动。

• 查看当前值：SHOW VARIABLES LIKE 'wait_timeout';，建议调低到60到120秒
• ThinkPHP配置里加上 'break_reconnect' => true，用来应对MySQL主动断连后的重连逻辑
• 务必配置 'params' => [PDO::ATTR_TIMEOUT => 5]，否则PDO新建连接时可能卡在系统TCP超时上（Linux默认75秒），进一步拖慢释放节奏
• 压测时定期跑 SHOW PROCESSLIST; 抓快照，对比不同时间点的Sleep连接增长趋势，这比单纯看总数更有诊断价值

真正难排查的是连接泄漏：某次异常中断导致Db::close()没执行，或者事务闭包里忘了释放资源。这类问题不会立刻报错，但几天后突然崩——所以开发期就要养成查PROCESSLIST的习惯。