SQL 如何排查“连接数爆满”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判断来源，再针对性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 有硬上限，且修改后需重启实例（不支持热生效）

真正要盯的是连接生命周期：是不是每次请求都新建连接？有没有复用？有没有连接泄漏？这些比数字本身重要得多。