mysql报too many connections本质是活跃与睡眠连接数达max_connections上限，需立即执行三句命令确认水位：show variables like 'max_connections'; show status like 'threads_connected'; show status like 'max_used_connections'; 若threads_connected接近max_connections且多为sleep状态，说明连接未释放；临时可set global调大，永久须改my.cnf并同步调低wait_timeout、interactive_timeout及系统limitnofile。
MySQL 报 Too many connections，本质是当前活跃 + 睡眠连接数已达 max_connections 上限，新连接被直接拒绝。这不是网络或权限问题，而是服务端硬性配额触顶——必须立刻查清是配置太低、连接泄漏，还是两者兼有。
怎么快速确认当前连接压测到了哪一步
连得上 MySQL 就立刻执行三句命令，别猜：
-
SHOW VARIABLES LIKE 'max_connections';—— 看理论天花板是多少（MySQL 5.7+ 默认是 151） -
SHOW STATUS LIKE 'Threads_connected';—— 看此刻实际打开了多少连接（等价于SHOW PROCESSLIST;行数） -
SHOW STATUS LIKE 'Max_used_connections';—— 看历史峰值是否长期贴近max_connections，比如150/151就说明快崩了
如果 Threads_connected 接近甚至等于 max_connections，且大量状态为 Sleep，基本可断定：连接没释放，不是并发真高。
临时救急：在线改 max_connections 不重启
仅限紧急恢复，重启后失效。适合排查阶段或临时扛高峰：
- 用 root 或带
SUPER权限的账号登录 MySQL - 执行：
SET GLOBAL max_connections = 500;（数值按服务器内存保守设，每连接约多占几 MB 内存） - 立即验证：
SHOW VARIABLES LIKE 'max_connections';确认已生效
注意：SET GLOBAL 修改不写入配置文件，MySQL 重启即还原；SET PERSIST（MySQL 8.0.22+）可持久化到 mysqld-auto.cnf，但不如直接改配置文件清晰可控。
永久生效：改配置文件 + 检查系统级限制
只改 my.cnf 的 [mysqld] 段不够，常见翻车点在这儿：
- 在
[mysqld]下加：max_connections = 500（建议 300～1000，别盲目拉到 2000+） - 同步调低空闲回收时间：
wait_timeout = 300和interactive_timeout = 300，避免Sleep连接长期占坑 - Linux 下必须检查 systemd 限制（尤其 Docker 或 MariaDB）：
LimitNOFILE必须 ≥max_connections + 100，否则 MySQL 启动时会默默截断该值（例如你设 1000，实际只加载 214） - 改完配置后，务必
systemctl daemon-reload && systemctl restart mysql（或mariadb），再验证
改完不 reload、不 restart，或者 LimitNOFILE 没同步，是线上最常踩的两个隐形坑。
为什么调大了还是报错？重点盯这三个地方
很多团队改完 max_connections 发现问题依旧，大概率卡在以下环节：
- 应用层连接池（如 HikariCP、Druid）的
maximumPoolSize设得比 MySQL 的max_connections还大，等于主动撞墙 - 代码里用了
pymysql.connect(..., autocommit=False)却没显式conn.close()，或用了上下文管理但异常路径漏关 -
SHOW PROCESSLIST;里看到大量Sleep连接持续超 5 分钟，说明应用没正确复用连接，或连接池配置不合理（如minIdle=0导致频繁创建销毁）
真正稳定的解法从来不是无脑调高 max_connections，而是让每个连接用得短、放得快、复用稳——参数只是兜底，代码和配置才是根因。
