mysql报错“too many connections”本质是当前活跃连接总数超过max_connections上限，需用root执行三命令确认水位：show variables like 'max_connections'、show status like 'threads_connected'、show status like 'max_used_connections'；若threads_connected≥max_connections−1即告警，而预留的+1连接专供super用户应急登录。
MySQL 报错 Too many connections 时，不是“用户超限”，而是**当前活跃连接总数超过 max_connections 上限**；所谓“用户”只是连接的来源标识，真正卡住的是连接槽位——哪怕全是同一个用户建的连接，只要总数满了，新连接照样被拒。
怎么确认是不是真连满了
必须用管理员账号（如 root）登录后立刻执行三句：
-
SHOW VARIABLES LIKE 'max_connections';—— 看上限（默认常是 151） -
SHOW STATUS LIKE 'Threads_connected';—— 看当前已连多少个 -
SHOW STATUS LIKE 'Max_used_connections';—— 看历史峰值，若长期接近上限，说明不是瞬时高峰，而是泄漏或配置不合理
注意：Threads_connected ≥ max_connections − 1 就可能触发拒绝；MySQL 允许 max_connections + 1 个连接，多出那 1 个是留给有 SUPER 权限用户的“救命通道”——你还能登进去，靠的就是它。
SET GLOBAL max_connections 为什么有时不生效
常见假象：命令返回成功，但查 SHOW VARIABLES LIKE 'max_connections' 还是旧值。根本原因通常是：
- 操作系统级文件描述符限制太低：
ulimit -n返回值（比如 1024）小于你想设的max_connections（比如 2000），MySQL 启动时会自动向下取整 - 配置写错了段落：必须在
[mysqld]段里写max_connections = 500，写在[client]或全局位置无效 - 多个配置文件冲突：MySQL 只加载一个主配置文件（可用
mysqld --help --verbose | grep "Default options"确认路径），后加载的覆盖前一个 - MySQL 8.0.22+ 用了
SET PERSIST：它会把值写进mysqld-auto.cnf，优先级高于my.cnf，改my.cnf不起作用
怎么安全清理僵死连接而不是硬 kill
别一上来就 KILL 所有 Sleep 连接——有些是正常长连接（比如监控、ETL 工具）。重点盯这些：
- 查出空闲太久的连接：
SELECT ID, USER, HOST, DB, COMMAND, TIME, STATE, INFO FROM information_schema.PROCESSLIST WHERE COMMAND = 'Sleep' AND TIME > 300;（>5 分钟的才考虑） - 按用户/IP 归类看异常来源：
SELECT USER, HOST, COUNT(*) FROM information_schema.PROCESSLIST GROUP BY USER, HOST ORDER BY COUNT(*) DESC; - 对确认无用的连接，用
KILL <code>ID;逐个终止；不要用KILL QUERY，它只停语句，连接还占着
更稳妥的做法是调低超时：SET GLOBAL wait_timeout = 120;（非交互式连接 2 分钟自动断开）
连 root 都登不上怎么办
当所有连接（含 Sleep）都已建立，预留的那 1 个管理连接也被占满时，SET GLOBAL 就没法执行了。此时必须绕过协议层：
- 先查出
mysqld进程 PID：ps aux | grep mysqld | grep -v grep - 用
gdb附加进程：gdb -p <pid></pid> - 在
gdb中执行：set $max_connections=1500（注意不是 SQL，是 C 变量赋值） - 输入
detach后quit退出，立刻尝试mysql -uroot -p
这个操作不重启、不丢数据，但属于非常规手段；MySQL 8.0.23+ 对 gdb 注入限制更严，生产环境务必提前验证兼容性。长期来看，应启用 MySQL 8.0.14+ 的管理连接接口（admin_address + admin_port），它不受 max_connections 限制，且无需 gdb 干预。
