应先查活跃连接而非直接调大max_connections：执行SELECT id,user,host,db,command,time,state,info FROM information_schema.PROCESSLIST WHERE command != 'Sleep' ORDER BY time DESC，重点关注time大、command为Query/Execute的连接，并根据host判断来源，再针对性kill或优化连接管理。
怎么查当前所有活跃连接及其来源
MySQL 报 Too many connections 时，第一反应不是调大 max_connections，而是先看谁在占着不放。用管理员账号执行：
SELECT id, user, host, db, command, time, state, info FROM information_schema.PROCESSLIST WHERE command != 'Sleep' ORDER BY time DESC;
重点关注 time 值大的、command 是 Query 或 Execute 的行——它们大概率是慢查询或卡住的事务。注意 host 字段：如果是 192.168.1.100:54321 这种带端口的，说明是短连接频繁建立；如果是 localhost 或 127.0.0.1，可能是本地脚本或定时任务没关连接。
哪些客户端最容易漏关连接导致堆积
PHP 的 mysqli 和 PDO 默认不自动回收连接，Python 的 pymysql、mysql-connector-python 也一样。常见陷阱包括：
- 脚本里用
try/except捕获异常但忘了conn.close() - Web 请求处理完没显式关闭连接，依赖 GC（尤其 PHP-FPM 下不可靠）
- 使用连接池但
max_idle_time或max_lifetime设得过大，空闲连接长期不释放 - Java 项目用了 HikariCP 却把
maximumPoolSize设成 200，而数据库只允许 150 连接，结果排队+超时+重试=雪崩
如何快速 kill 掉可疑连接
别直接杀 id，先确认它没在做关键事务：
SELECT trx_id, trx_state, trx_started, trx_query FROM information_schema.INNODB_TRX WHERE trx_mysql_thread_id = 12345;
如果 trx_state 是 running 且 trx_query 非空，谨慎操作；否则可安全终止：
KILL 12345;
批量清理长时间 Sleep 连接（比如超过 300 秒）：
SELECT CONCAT('KILL ', id, ';')
FROM information_schema.PROCESSLIST
WHERE command = 'Sleep' AND time > 300;
复制输出结果，再批量执行——避免误杀正在认证或握手中的新连接。
max_connections 不是万能解药
盲目调高 max_connections 可能掩盖真正问题，还带来额外开销：
- 每个连接至少占用 256KB 内存（取决于
sort_buffer_size等），设成 1000 就多占 256MB - Linux 默认单进程文件描述符限制常为 1024，MySQL 实际能用的连接数可能被系统级限制卡住
- 很多云数据库（如阿里云 RDS）对
max_connections有硬上限，且修改后需重启实例（不支持热生效）
真正要盯的是连接生命周期：是不是每次请求都新建连接？有没有复用？有没有连接泄漏？这些比数字本身重要得多。
