“too many connections”是连接资源耗尽信号，非安全漏洞但致服务不可用；根本解法是启用mysql 8.0+独立管理端口（admin_port=33062），并同步检查系统文件描述符、内存占用及应用连接池上限。
“Too many connections”不是安全漏洞，而是连接资源耗尽的明确信号；它本身不泄露数据，但会引发服务不可用、监控失效、故障排查失能等连锁风险——真正的安全隐患在于你连不上数据库去杀连接、查日志、做响应。
为什么连不进 MySQL 时 root 也失败？
MySQL 在 max_connections 耗尽后，普通连接（包括 root）全被拒绝。但 8.0+ 版本默认预留了 1 个 SUPER 权限连接名额，前提是：你用的是本地 socket 或 127.0.0.1（非 localhost），且未触发系统级限制。
更关键的是：这个“预留通道”在连接满时极不可靠——一旦有长事务或卡死线程占着它，你就彻底失联。所以必须提前启用独立管理端口：
- 编辑
my.cnf，在[mysqld]段添加：admin_address=127.0.0.1和admin_port=33062 - 重启 MySQL（
systemctl restart mysqld），之后可用mysql -u root -P 33062 -h 127.0.0.1 -p登录，该连接不计入max_connections，也不受wait_timeout影响 - 注意：此端口仅监听本地，不可绑定到
0.0.0.0，否则暴露管理面
kill 连接前必须确认的三件事
盲目执行 KILL 可能中断正在提交的事务、损坏一致性，尤其在主从或 CDC 场景下。
- 先运行
SHOW PROCESSLIST;，过滤掉State = 'Query'且Time > 60的线程——它们大概率是慢 SQL 或锁等待，杀掉可能让问题恶化 - 重点 kill
Command = 'Sleep'且Time > 300的连接，这类基本是应用层未 close() 的泄漏连接 - 避免批量 kill 所有 Sleep：某些健康连接池（如 HikariCP）会维持少量空闲连接用于快速响应，杀光反而引发重连风暴
wait_timeout 改小真会断业务吗？
会，但只影响“空闲连接”，不影响正在执行的查询。很多线上事故源于把 wait_timeout 从 28800（8 小时）直接砍到 30 秒，而应用没做连接有效性检测。
- 安全做法：分两步走。先设为
300（5 分钟），观察 24 小时内是否有应用报MySQL server has gone away - 若出现，说明应用存在长空闲期后直接复用旧连接的行为，需在代码里加
testOnBorrow=true（DBCP）或connection-test-query=SELECT 1（HikariCP） - Linux 层的
tcp_keepalive_time（默认 7200 秒）和 MySQL 的wait_timeout是两套机制，后者优先生效，前者仅兜底防中间设备断连
max_connections 设多大才算不埋雷？
没有固定值，但超 1000 就得同步检查三个硬限制，缺一不可：
- 操作系统文件描述符：
ulimit -n必须 ≥max_connections + 200（留出日志、socket 等开销），systemd 服务需在[Service]段加LimitNOFILE=65536 - 内存占用：每个连接基础消耗约 256KB–1MB，16GB 内存机器设 2000 连接，仅连接内存就吃掉 500MB–2GB，再叠加排序/临时表缓冲区极易 OOM
- 应用连接池上限：HikariCP 的
maximumPoolSize必须 ≤ MySQL 的max_connections，且所有微服务总和不能突破该值，否则抢连导致其他服务失联
最常被忽略的一点：MySQL 8.0.22+ 的 SET PERSIST 命令会写入 mysqld-auto.cnf，其配置优先级高于 my.cnf。改完配置文件却没生效？先查这个文件。
