应调小wait_timeout和interactive_timeout（如设为60），及时释放空闲Sleep连接；优先优化应用层连接复用与正确关闭，而非盲目增大max_connections。
MySQL 连接数爆满时，show processlist 看到大量 Sleep 状态连接怎么办
这不是“连接数多”本身的问题，而是大量空闲连接没释放，占着线程和内存不干活。MySQL 默认每个连接独占一个线程，Sleep 连接持续存在会快速耗尽 max_connections，新请求只能排队或直接被拒。
实操建议：
- 先查真实活跃连接：
SELECT * FROM information_schema.PROCESSLIST WHERE COMMAND != 'Sleep';，别只盯着总数 - 立刻清理长期空闲连接：
KILL掉TIME值远超业务合理范围（比如 > 300 秒）的Sleep连接 - 确认应用是否用了连接池但没正确 close —— 很多 Java 应用在 finally 块漏掉
connection.close()，或用完ResultSet/Statement没关，导致物理连接未归还 - 临时缓解：调大
wait_timeout和interactive_timeout反而更糟，应**调小**（如设为 60），让空闲连接更快释放
调整 max_connections 前必须看懂这三件事
盲目增大 max_connections 是最常见误区。它不是“越大越好”，而是受制于系统资源和 MySQL 自身开销。
实操建议：
-
max_connections每增加 1，MySQL 至少多占 256KB 内存（线程栈 + 连接结构体），1000 连接 ≈ 256MB 额外常驻内存 - Linux 默认单进程最大文件描述符数（
ulimit -n）通常为 1024，若max_connections设为 2000，MySQL 启动会失败并报错：Can't create thread (errno: 24) - 真正需要调大的场景极少：通常是短连接高频突增（如秒杀），且已确认应用层无法复用连接；否则优先优化连接复用，而非堆参数
PHP/Python/Java 应用里，mysql_connect() 和 mysql_pconnect() 别乱用
mysql_pconnect()（持久连接）在 PHP 中容易引发连接泄漏，尤其在 FPM 模式下：子进程退出时不销毁连接，连接留在 MySQL 里变成 Sleep，最终堆积满。
实操建议：
- PHP-FPM 场景下，禁用
mysql_pconnect()，改用普通mysqli_connect()+ 连接池中间件（如 ProxySQL）或应用层连接池（如 Laravel 的 DB::connection() 默认已做复用） - Python 的
pymysql默认不持久，但若手动复用Connection对象且没调close()，效果等同于持久连接 - Java 的
DataSource（如 HikariCP）必须配maxLifetime和idleTimeout，否则连接池里的连接可能比 MySQL 的wait_timeout活得更久，造成“假死连接”
Aborted_connects 持续上涨，说明连接根本没建成功
这个状态变量增长，意味着客户端连不上 MySQL，不是慢，是失败。常见于认证失败、网络中断、连接被防火墙拦截，或 MySQL 正在拒绝新连接（因已达 max_connections 上限）。
实操建议：
- 查日志：
SHOW VARIABLES LIKE 'log_warnings';开启后，错误日志里会出现类似Access denied for user 'xxx'@'yyy' (using password: YES)或Too many connections - 监控
Threads_created：如果该值飙升，说明连接频繁重建，大概率是应用没复用连接，或连接池配置过小 - 用
tcpdump抓包看三次握手是否完成、SYN 包有没有回 ACK——有时问题根本不在于 MySQL，而在中间 LB 或安全组限制了并发新建连接速率
真正卡住响应的，往往不是连接数上限本身，而是连接生命周期管理失控。一个没关的 ResultSet，一次漏写的 finally close()，或一段被注释掉的连接池配置，比 max_connections = 2000 更危险。
