先确认是否真打满：用root socket直连执行SHOW VARIABLES LIKE 'max_connections'; SHOW STATUS LIKE 'Threads_connected';，若后者接近或等于前者且持续报ERROR 1040，才算真正打满；注意Waiting in connection_control plugin等认证阻塞连接不计入但会占位。
怎么确认是不是真的连接数打满了
别急着改配置，先看真实连接状态。用 root 用户通过 socket 直连（绕过 TCP 限制）执行：
mysql -u root -p -S /var/lib/mysql/mysql.sock -e "SHOW VARIABLES LIKE 'max_connections'; SHOW STATUS LIKE 'Threads_connected';"
如果 Threads_connected 接近或等于 max_connections，且新连接持续报 ERROR 1040 (HY000): Too many connections，才算真正打满。注意：有些情况是连接卡在认证阶段（比如 Waiting in connection_control plugin），实际并未计入活跃连接，但会阻塞新连接建立。
哪些连接最该优先 kill
不是所有连接都值得保留。登录后执行 SHOW FULL PROCESSLIST，重点关注这几类：
-
Command是Connect且State为Waiting in connection_control plugin：大概率是密码错误反复重试，可批量清理 -
Time> 600 秒的Sleep连接：应用没释放，基本可 kill -
Command是Query且Time> 300 秒、Info显示明显慢 SQL（如无索引 JOIN、ORDER BY大结果集）：先记录 ID，再 kill - 来自同一
Host的大量短生命周期连接（Time
清理命令示例：KILL 12345; 或批量生成：SELECT CONCAT('KILL ', id, ';') FROM information_schema.PROCESSLIST WHERE TIME > 600 AND COMMAND = 'Sleep';
查连接泄漏不能只看代码 close() 调用
很多团队检查了所有 close()，还是漏掉连接。真正容易被忽略的是：
- 事务中调用了外部 HTTP/RPC，超时后连接未 rollback 就抛异常退出
- ORM 框架嵌套事务（如 Spring 的
@Transactional嵌套），外层异常导致内层连接未归还连接池 - 异步线程里开了数据库连接，主线程结束但子线程还在跑，连接池无法回收
- 连接池配置了
maxIdle过大（比如设为 100），空闲连接长期不销毁，堆积占满上限
验证方式：重启应用后观察 Threads_connected 是否随请求量线性增长且不回落——这是典型泄漏特征。
临时扩容 max_connections 有哪些坑
直接调大 max_connections 是最快恢复手段，但必须同步做三件事，否则很快又爆：
- 系统级文件描述符要跟上：Linux 默认
ulimit -n通常只有 1024，MySQL 每个连接至少占用 1 个 fd，需在/etc/security/limits.conf中为 mysql 用户设nofile至少 65535 - 内存必须足够：每个连接约消耗 256KB～1MB 内存（取决于 buffer 设置），
max_connections=1000可能额外吃掉 1GB+ 内存 - 必须配合连接池最大连接数下调：比如 HikariCP 的
maximumPoolSize应 ≤max_connections / 应用实例数，否则多实例叠加仍超限
改完记得写进 my.cnf 的 [mysqld] 段，否则重启失效。
连接数问题从来不是单点故障，而是代码、配置、SQL、运维四层耦合的结果。最容易被跳过的环节，是查 SHOW PROCESSLIST 时忽略 State 和 Time 的组合含义——比如大量 Sleep + 高 Time 不一定是泄漏，也可能是连接池设置了过长的 maxLifetime，导致连接“老而不死”。
