MySQL服务端max_connections被占满导致“Too many connections”错误，需检查Threads_connected是否接近max_connections阈值，并优化连接管理：禁用PDO持久连接、显式关闭MySQLi连接、合理设置wait_timeout（60–300秒）及配合PHP-FPM重启策略。
“Too many connections”不是PHP代码写错了，是MySQL服务端拒绝新连接——max_connections被打满了。 你看到的报错来自 PDO::__construct() 或 mysqli_connect()，但根源不在PHP脚本语法，而在连接没被真正释放、堆积在MySQL服务端。
查清当前连接数和上限
登录MySQL后立刻执行这两条命令，5秒内就能确认是不是真被占满了：
-
SHOW VARIABLES LIKE 'max_connections';—— 看MySQL允许的最大并发连接数（默认常为151或1000） -
SHOW STATUS LIKE 'Threads_connected';—— 看当前已建立的连接数，接近前者就基本坐实了
注意：Threads_connected 不包含“已失效但未回收”的连接（比如脚本异常退出、没执行 mysqli_close()），压测时实际连接数可能更高。如果值长期卡在90%以上，说明连接生命周期管理出问题了。
禁用PDO持久连接并显式置空对象
PDO默认不启用持久连接，但一旦你在DSN里加了 'persistent' => true 或设置了 PDO::ATTR_PERSISTENT => true，在PHP-FPM环境下极易引发连接堆积：子进程退出时不真正断开，而是把连接“还”给内部池，而这个池不会主动清理空闲或失效连接。
立即学习“PHP免费学习笔记（深入）”；
- 生产环境一律设
PDO::ATTR_PERSISTENT => false（即使没显式设，也要在构造时明确传入） - 避免在循环或高频函数中反复
new PDO()，应统一由工厂类或依赖注入容器管理单例 - 脚本结束前强制释放：用完后写
$pdo = null;，而不是只靠脚本自动销毁——异常中断时这步容易被跳过
示例安全写法：
$pdo = new PDO($dsn, $user, $pass, [
PDO::ATTR_PERSISTENT => false,
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
PDO::ATTR_TIMEOUT => 5,
]);
MySQLi连接必须显式关闭，不能只靠脚本结束
MySQLi面向对象方式下，new mysqli() 创建的连接**不会**在脚本结束时自动关闭（尤其在PHP-FPM长生命周期worker中），必须手动调用 $mysqli->close() 或至少 $mysqli = null;。
- 过程式调用
mysql_connect()已废弃且不可靠，绝对不要用 - 循环中创建多个
mysqli实例却没close()，是连接数暴涨最常见原因 - 异常发生时
close()容易被跳过，建议用try/finally包裹：
try {
$mysqli = new mysqli($host, $user, $pass, $db);
// 执行查询...
} finally {
$mysqli?->close(); // PHP 8.0+ 可选链，兼容老版本请先判空
}
wait_timeout设太长会让“假空闲”连接滞留数小时
MySQL默认 wait_timeout = 28800（8小时），意味着一个空闲连接可以挂在那里等8小时才被回收。而PHP脚本通常几毫秒就结束了，这些连接其实是“僵尸”——没人用，但MySQL还认为它合法。
- 线上务必改小：
wait_timeout = 60或300（秒），配合interactive_timeout = 60 - 修改后需重启MySQL或执行
SET GLOBAL wait_timeout = 60;（临时生效） - 这个值要和PHP-FPM的
pm.max_requests协同：比如设为300，表示每个worker最多处理300个请求就重启，强制清理所有残留连接
最容易被忽略的一点：wait_timeout 调得太低（如10秒），反而会导致正常慢查询被误杀；调太高（如7200），又让无效连接霸占名额。60–300是多数业务的安全平衡点。
