首要动作是执行SHOW PROCESSLIST或查询information_schema.PROCESSLIST过滤非Sleep且Time>300的会话，通过Host列定位客户端IP和端口，结合Command、State、Time判断连接异常类型，并配合应用侧连接池监控与日志分析根因。
查当前活跃连接和来源 IP
MySQL 报 Too many connections 时，首要动作不是重启，而是快速定位谁在占着连接不放。执行：
SHOW PROCESSLIST;
重点看 Host 列（格式通常是 xxx.xxx.xxx.xxx:port），能直接暴露客户端 IP 和端口；Command 列为 Sleep 且 Time 值很大（比如 > 300 秒）的，大概率是应用没正确关闭连接；State 是 Sending data 或 Locked 的，则可能卡在慢查询或锁等待上。
如果权限足够，更推荐用：
SELECT ID, USER, HOST, DB, COMMAND, TIME, STATE, INFO FROM information_schema.PROCESSLIST WHERE COMMAND != 'Sleep' OR TIME > 300;
这样过滤掉大量无意义的空闲连接，聚焦可疑会话。
区分应用连接池与真实客户端
看到 HOST 是 127.0.0.1:xxxxx 或 localhost，别急着认为是本地脚本——它更可能是中间件（如 Nginx + PHP-FPM、Tomcat、Node.js 进程）发起的连接。真实来源需结合应用日志或部署结构判断：
- Java 应用常用 HikariCP/Druid，检查
spring.datasource.hikari.maximum-pool-size是否设得过大（如 100+），且未配置connection-timeout或idle-timeout - PHP 的
mysqlnd默认不复用连接，mysqli每次 new 一个实例就新建连接，容易在循环里失控 - Python 的
pymysql或mysql-connector-python若没用with或显式close()，连接会在 GC 前一直挂着
单纯靠 MySQL 端无法区分“同一个 IP 下的多个进程”，必须配合应用侧连接池监控（如 HikariCP 的 /actuator/metrics/hikaricp.connections.active）。
临时释放连接 + 防止雪崩
确认某类连接异常后，可手动 kill：
