MySQL连接Too many connections错误的解决方法

先别急着修改配置参数。即使应用已经无法连接，通过本地 socket 使用 root 账户仍然可以登录——MySQL 专门为拥有 SUPER 权限的管理员预留了一个紧急连接通道。登录后，请立即执行以下三条语句，快速摸清当前状况：

• SHOW VARIABLES LIKE 'max_connections'; —— 查看连接上限，默认值通常为 151
• SHOW STATUS LIKE 'Threads_connected'; —— 当前已建立的连接数量
• SHOW STATUS LIKE 'Max_used_connections'; —— 历史峰值，比瞬时值更具参考性

当 Threads_connected 接近 max_connections 上限，而 Threads_running 却非常低时（例如 500 个连接中只有 2 个正在运行），说明连接大多处于 Sleep 状态，通常是由连接泄漏或空闲连接堆积导致的问题。

为什么 SET GLOBAL max_connections 经常不生效

执行 SET GLOBAL max_connections = 1000; 后，查询变量发现仍是旧值？问题并不在于 MySQL 本身，而是受到以下三个硬性限制：

• 运行 ulimit -n 查看系统限制，若返回 1024，而你想设置 2000，MySQL 在启动时会自动向下取整
• 对于 systemd 管理的服务，需在 /usr/lib/systemd/system/mysqld.service 的 [Service] 部分添加 LimitNOFILE=65536 和 LimitNPROC=65536，然后执行 systemctl --system daemon-reload && systemctl restart mysqld 使其生效
• MySQL 8.0.22 及以上版本支持 SET PERSIST max_connections = 1000;，该命令会写入 mysqld-auto.cnf 文件，其优先级高于 my.cnf——如果已经使用此方式，直接修改配置文件将无法覆盖

连接池的 idleTimeout 和 wait_timeout 必须匹配

多数线上故障的根源其实在于应用端。例如 HikariCP 或 Druid 连接池常见的配置错误：

• max-active（Druid）或 maximumPoolSize（HikariCP）设置得比 max_connections 还高，多个服务同时请求时就会导致连接数爆满
• wait_timeout 设置为 300 秒，但连接池的 idleTimeout 却设为 600 秒，导致连接永远无法归还
• HikariCP 的 connection-timeout 默认值为 30 秒，在网络波动时容易造成连接堆积；建议调整为 10–15 秒，并启用 leak-detection-threshold 检测泄漏

核心原则：idleTimeout 必须严格小于 wait_timeout，否则连接被 MySQL 断开后，连接池仍认为其有效，下次使用时就会报错。

kill Sleep 连接只是应急，不是解法

通过 SHOW PROCESSLIST; 看到大量 Sleep 连接，KILL 掉可以临时释放几个名额，但几小时后又会满——因为连接泄漏仍在持续。

重点排查 USER 和 HOST：

• 使用 SELECT USER, HOST, COUNT(*) FROM information_schema.PROCESSLIST GROUP BY USER, HOST; 定位异常的 IP 或账号
• 对确认无用的连接，使用 KILL ID; 逐个终止；注意不要使用 KILL QUERY，它仅停止当前语句，连接仍然占用
• 更稳妥的方法是降低超时时间：SET GLOBAL wait_timeout = 120;（非交互式连接 2 分钟自动断开），SET GLOBAL interactive_timeout = 180;（交互式连接 3 分钟自动断开）

真正棘手的是那些没有显式关闭连接的代码路径：当 PHP 脚本发生 fatal error 时，mysqlnd 不会自动归还连接，必须显式调用 mysqli_close()；在 Java 里 try 块中忘记在 finally 中执行 conn.close()，同样会导致连接堆积。