MySQL报Too many connections错误是连接数达max_connections上限所致，并非数据库宕机；root用户可通过socket直连排查，确认Threads_connected是否接近max_connections，并检查Sleep连接、wait_timeout等根因。
MySQL 报 Too many connections 错误，说明当前连接数已达到 max_connections 上限，新连接被直接拒绝——这不是数据库挂了，而是“门关了”，但 root 用户通过 socket 仍能进（预留一个管理连接），这点必须先确认。
怎么看当前连接是否真打满了
别急着改配置，先用最轻量方式验证现状：
- 用 socket 直连（绕过 TCP 限制）：
mysql -uroot -p -S /var/lib/mysql/mysql.sock -e "SHOW STATUS LIKE 'Threads_connected'; SHOW VARIABLES LIKE 'max_connections';" - 如果
Threads_connected接近或等于max_connections（比如 150/151），就是真满了；如果差很多，可能是网络、权限或客户端配置问题 -
SHOW PROCESSLIST;看状态：大量Sleep且Time超过几十秒的连接，大概率是空闲未释放，不是活跃业务请求 - 注意：
Threads_running才代表真正执行 SQL 的连接数，它远小于Threads_connected时，基本可断定是连接泄露或空闲堆积
为什么连接数会爆满（常见根因）
调大 max_connections 只是止血，不查根因，几天后还会复发。高频真实原因有：
- 应用代码没关闭连接：比如 Python 的
cursor.close()或 Java 的Connection.close()漏写，尤其在异常分支里没包进finally - 连接池配置失当：
max-active=100但部署了 5 个微服务实例，每个都连满，合计 500 连接压向 MySQL -
wait_timeout设得过大（如 28800 秒 = 8 小时），客户端断开后连接还在 MySQL 端挂着，Sleep状态持续占坑 - 慢查询或长事务卡住连接：一条没索引的
SELECT * FROM huge_table WHERE ...卡住 30 秒，连接就在这 30 秒内无法复用 - 脚本类任务直连 MySQL：定时任务用 PHP/Python 脚本每次新建连接又不显式关闭，跑一次留一个
Sleep连接
临时应急：安全清理 + 快速恢复
连接满时，mysqladmin 常常连不上，不能硬 kill -9，否则可能丢数据：
- 先找 mysqld 主进程 PID：
ps aux | grep 'mysqld ' | grep -v grep | awk '{print $2}'（注意结尾空格，避免匹配到 mysqld_safe） - 发安全退出信号：
kill -TERM $PID，MySQL 会等现有连接自然结束、刷盘后再退出 - 重启后立即检查：
mysql -S /var/lib/mysql/mysql.sock -e "SHOW PROCESSLIST;" | wc -l，确认连接数回落 - 若需立刻释放部分连接，且还能进 MySQL：
KILL [Id]杀掉Time特别长的Sleep连接（别杀Command=Query的）
永久修复：配置 + 应用双改
只改 MySQL 配置治标，只改应用代码治本，两者必须一起做：
- MySQL 层：
/etc/my.cnf中设max_connections = 500（按业务峰值 ×1.5 估算），同时调低wait_timeout = 60（单位秒），强制空闲连接快速释放 - 系统层检查：
ulimit -n和cat /proc/sys/fs/file-max，确保系统文件描述符够用，否则 MySQL 启动时实际连接数仍受限 - 应用层必须加连接池：PHP 用 PDO + persistent connection 要慎用（易泄漏），推荐 Swoole 协程池；Java 用 HikariCP 并设
connection-timeout=30000、idle-timeout=600000 - 所有数据库操作必须包裹在
try/finally或使用语言级资源管理（如 Python 的with conn:），确保close()必执行
最容易被忽略的是：多个服务共用一个数据库账号时，max_user_connections 也可能成为瓶颈，需一并检查 SELECT User, Host, max_user_connections FROM mysql.user;。
