先别急着修改配置参数。即使应用已经无法连接，通过本地 socket 使用 root 账户仍然可以登录——MySQL 专门为拥有 SUPER 权限的管理员预留了一个紧急连接通道。登录后，请立即执行以下三条语句，快速摸清当前状况：
SHOW VARIABLES LIKE 'max_connections';—— 查看连接上限，默认值通常为 151SHOW STATUS LIKE 'Threads_connected';—— 当前已建立的连接数量SHOW STATUS LIKE 'Max_used_connections';—— 历史峰值，比瞬时值更具参考性
当 Threads_connected 接近 max_connections 上限，而 Threads_running 却非常低时（例如 500 个连接中只有 2 个正在运行），说明连接大多处于 Sleep 状态，通常是由连接泄漏或空闲连接堆积导致的问题。
为什么 SET GLOBAL max_connections 经常不生效
执行 SET GLOBAL max_connections = 1000; 后，查询变量发现仍是旧值？问题并不在于 MySQL 本身，而是受到以下三个硬性限制：
- 运行
ulimit -n查看系统限制，若返回 1024，而你想设置 2000，MySQL 在启动时会自动向下取整 - 对于 systemd 管理的服务，需在
/usr/lib/systemd/system/mysqld.service的[Service]部分添加LimitNOFILE=65536和LimitNPROC=65536，然后执行systemctl --system daemon-reload && systemctl restart mysqld使其生效 - MySQL 8.0.22 及以上版本支持
SET PERSIST max_connections = 1000;，该命令会写入mysqld-auto.cnf文件，其优先级高于my.cnf——如果已经使用此方式，直接修改配置文件将无法覆盖
连接池的 idleTimeout 和 wait_timeout 必须匹配
多数线上故障的根源其实在于应用端。例如 HikariCP 或 Druid 连接池常见的配置错误：
max-active（Druid）或maximumPoolSize（HikariCP）设置得比max_connections还高，多个服务同时请求时就会导致连接数爆满wait_timeout设置为 300 秒，但连接池的idleTimeout却设为 600 秒，导致连接永远无法归还- HikariCP 的
connection-timeout默认值为 30 秒，在网络波动时容易造成连接堆积；建议调整为 10–15 秒，并启用leak-detection-threshold检测泄漏
核心原则：idleTimeout 必须严格小于 wait_timeout，否则连接被 MySQL 断开后，连接池仍认为其有效，下次使用时就会报错。
kill Sleep 连接只是应急，不是解法
通过 SHOW PROCESSLIST; 看到大量 Sleep 连接，KILL 掉可以临时释放几个名额，但几小时后又会满——因为连接泄漏仍在持续。
重点排查 USER 和 HOST：
- 使用
SELECT USER, HOST, COUNT(*) FROM information_schema.PROCESSLIST GROUP BY USER, HOST;定位异常的 IP 或账号 - 对确认无用的连接，使用
KILL ID;逐个终止；注意不要使用KILL QUERY，它仅停止当前语句，连接仍然占用 - 更稳妥的方法是降低超时时间：
SET GLOBAL wait_timeout = 120;（非交互式连接 2 分钟自动断开），SET GLOBAL interactive_timeout = 180;（交互式连接 3 分钟自动断开）
真正棘手的是那些没有显式关闭连接的代码路径：当 PHP 脚本发生 fatal error 时，mysqlnd 不会自动归还连接，必须显式调用 mysqli_close()；在 Java 里 try 块中忘记在 finally 中执行 conn.close()，同样会导致连接堆积。
