立刻执行set global max_connections = 500（需super权限），并检查ulimit -n及systemd limitnofile限制；再用select统计连接来源，kill异常连接；长期须配连接池、设timeout、加监控。
MySQL 报错 Too many connections 怎么立刻放行？
直接改 max_connections 全局变量，不用重启 MySQL。只要还有至少一个连接可用（比如你正用 root 连着），就能执行：
SET GLOBAL max_connections = 500;这个值别瞎设太高——Linux 默认单进程文件描述符上限通常是 1024，MySQL 每个连接至少占 1 个 fd，设到 1000 以上得先确认
ulimit -n 和 mysqld 启动用户的 limits 配置，否则 mysqld 会静默失败或后续崩溃。
为什么 SET GLOBAL 改了却没生效？
常见原因就三个：
- 权限不足：必须有
SUPER或SYSTEM_VARIABLES_ADMIN权限，普通 DBA 账号可能没有 - 改的是 session 级：写成了
SET max_connections = 500（缺GLOBAL），这个只影响当前会话，完全没用 - 配置文件锁死：如果
my.cnf里写了max_connections = 151且 MySQL 是 systemd 启动，某些发行版（如 RHEL/CentOS）的LimitNOFILE会卡住实际可分配值，此时光改变量没用
临时调高后，怎么查谁在疯狂建连？
立刻跑这句：
SELECT user, host, COUNT(*) AS cnt FROM information_schema.processlist GROUP BY user, host ORDER BY cnt DESC LIMIT 10;重点关注
user 为空或为 unauthenticated user 的行——大概率是应用没关连接、DNS 解析失败重试、或者被暴力扫描。另外看 TIME 列超 60 秒还 Sleep 的连接，基本是应用层连接池泄漏。别急着 kill，先 SHOW PROCESSLIST 对照 PID，再用 KILL [id] 逐个清理可疑连接。
下次还能不能避免连不上？
核心是别依赖“临时加数”：
- 应用必须配连接池（如 HikariCP 的
maximumPoolSize）并设合理上限，禁止直连 + 不关连接 - MySQL 配置里
wait_timeout和interactive_timeout建议设成 300（5 分钟），避免空闲连接长期占坑 - 监控必须覆盖
Threads_connected和Threads_running，阈值设在 80%max_connections就告警
