MySQL 连接数满了怎么处理？先救急再调参的完整步骤

MySQL 提示 Too many connections 时，数据库已经无法接受新连接，业务会直接报错。
先做两件事：确认当前连接数是否真的达到上限，以及这些连接是被谁占着。
多数情况不是上限太小，而是有大量空闲连接或慢查询没有释放。

下面按“先恢复可用、再调整上限、最后排查应用侧”的顺序处理，适合 MySQL 5.7 和 8.0，前提是你有能登录数据库的账号，或者有服务器 root 权限。

先判断是连接打满还是连接堆积

登录 MySQL 后执行：

SHOW STATUS LIKE 'Threads_connected';
SHOW VARIABLES LIKE 'max_connections';

Threads_connected 接近 max_connections 说明连接数已到上限。
接着看连接状态：

SHOW PROCESSLIST;

重点看 Command 为 Sleep 的连接数量和 Time 较大的查询。
如果大量连接处于 Sleep 且时间很长，说明应用没有正确释放连接，单纯调大上限只会让问题延后。
如果看到大量 Query 且 Time 很大，需要先处理慢 SQL。

还有一个容易忽略的点：max_connections 不是唯一上限，max_user_connections 也可能限制单个账号的连接数。

救急：清理空闲连接并临时提高上限

如果业务已经不可用，先临时调大上限让新连接能进来。
MySQL 8.0 支持在线修改：

SET GLOBAL max_connections = 500;

MySQL 5.7 同样支持这条语句，但要注意它只对之后的新连接生效。
临时调大后，观察 Threads_connected 是否仍然持续上涨。

对于确认空闲的 Sleep 连接，可以按 ID 逐个杀掉：

KILL 12345;

不要一次性杀掉所有连接，尤其不要动正在执行写操作的连接。
更稳妥的做法是只清理 Sleep 时间超过阈值的连接，例如用脚本筛选 Time 大于 600 秒的 Sleep 连接。

如果连登录都失败，可以在服务器上用 root 通过本地 socket 登录，或者临时在配置中增加 max_connections 后重启 MySQL。
重启会中断现有连接，需评估业务影响。

持久化修改并评估合理上限

临时修改在重启后会失效。
要持久化，编辑 MySQL 配置文件，通常路径是 /etc/my.cnf 或 /etc/mysql/mysql.conf.d/mysqld.cnf，在 [mysqld] 段落下增加：

[mysqld]
max_connections = 500
wait_timeout = 300
interactive_timeout = 300

wait_timeout 控制非交互连接空闲多久后被断开，interactive_timeout 控制交互式连接。
把空闲超时调短可以减少连接堆积，但不要设得过低，否则可能误断正常的长连接应用。

调大 max_connections 不是越大越好。
每个连接都会占用内存，连接数过高可能导致内存耗尽。
一个粗略的评估方法是：在业务高峰观察 Threads_connected 的峰值，把上限设为峰值的 1.5 到 2 倍，同时留出管理连接的空间。
更准确的内存评估需要结合 innodb_buffer_pool_size 和每个连接的内存开销，不能只看连接数。

修改配置后重启 MySQL 或执行 SET GLOBAL 让参数生效，然后再次确认：

SHOW VARIABLES LIKE 'max_connections';
SHOW VARIABLES LIKE 'wait_timeout';

排查应用侧连接池和慢查询

连接数反复打满，通常要从应用侧找原因。
检查连接池配置是否设置了最大连接数、空闲连接回收和连接超时。
以常见的 Java 连接池为例，maximumPoolSize 不应超过数据库能承受的连接数，idleTimeout 和 maxLifetime 要小于数据库的 wait_timeout，否则应用会拿到已被数据库断开的连接。

同时检查是否有慢查询长期占用连接：

SHOW FULL PROCESSLIST;

关注 Time 很大的语句，结合 EXPLAIN 分析执行计划。
慢查询不解决，连接释放速度跟不上创建速度，调大上限只能暂时缓解。

另外确认应用是否在每次请求都新建连接而没有归还，这类连接泄漏会让连接数只增不减。

验证是否真正恢复

处理完成后，从两个层面验证：

1. 在数据库执行 SHOW STATUS LIKE 'Threads_connected';，观察数值是否稳定在合理范围，不再持续逼近上限。
2. 从应用侧发起正常请求，确认不再出现 Too many connections 报错。

如果连接数仍然快速上涨，回到 SHOW PROCESSLIST 看新增连接的状态和来源，重点排查连接池配置和慢查询。

常见疑问

调大 max_connections 后需要重启吗？

SET GLOBAL 立即生效但不持久，重启后恢复原值；
修改配置文件需要重启或重新加载配置才持久生效。

为什么连接数没到 max_connections 也报连接错误？

可能是 max_user_connections 限制、服务器文件描述符不足，或者连接在握手阶段就被拒绝。
需要结合 MySQL 错误日志确认具体原因。

wait_timeout 调小会不会影响业务？

如果应用连接池的空闲回收时间大于 wait_timeout，可能出现连接被数据库断开后应用仍在使用的情况。
调整时要让连接池的 maxLifetime 小于 wait_timeout，并观察业务是否出现连接异常。