mysql连接数爆满时，应先用root@localhost的socket连接登录；若失败则检查文件描述符限制；再通过performance_schema定位长时sleep或锁等待连接；kill前须排除binlog dump等关键线程；盲目调大max_connections易致oom，应合理设置timeout参数。
连接数爆满时，先连得上再说
别急着改配置或杀进程，第一步是确保你能登录进去。MySQL 在 max_connections 打满时，会为 root@localhost 预留一个 socket 连接位——这是唯一能绕过 TCP 限制的后门。
执行：mysql -u root -p -S /var/lib/mysql/mysql.sock
如果失败，说明系统级文件描述符也快耗尽了，得先看：cat /proc/$(pgrep mysqld)/limits | grep "Max open files"
低于 65535 就要同步调大 /etc/security/limits.conf 和 MySQL 的 open_files_limit。
快速定位“占坑不干活”的连接
连接数飙升但 CPU/IO 不高，大概率是大量连接卡在 Sleep 或锁等待状态，不是真忙，是被占着。
别用 SHOW PROCESSLIST，它只显示前 100 字 SQL，关键信息被截断；必须用：SELECT ID, USER, HOST, DB, COMMAND, TIME, STATE, INFO FROM performance_schema.processlist WHERE COMMAND != 'Sleep' AND TIME > 60 ORDER BY TIME DESC;
重点关注：
• STATE 是 Waiting for table metadata lock 或 Locked：说明有 DDL 或长事务阻塞
• TIME 超过 300 秒且 COMMAND 是 Query：基本可判定为慢 SQL 或未提交事务
• HOST 集中在某台应用服务器 IP：指向该服务连接池泄漏或未正确关闭连接
临时止血：精准 KILL，避开复制和监控线程
KILL 操作不能靠猜，否则可能干掉主从复制或监控探针。
先排除安全线程：SELECT ID, USER, HOST, COMMAND FROM information_schema.processlist WHERE COMMAND IN ('Binlog Dump', 'Connect', 'Daemon');
这些不要动。真正该清理的是：
• USER 是应用账号（如 app_user）且 TIME > 600 的 Sleep 连接
• STATE 为 Updating 或 Sending data 且持续超 5 分钟的查询
批量 KILL 示例：SELECT CONCAT('KILL ', id, ';') FROM information_schema.processlist WHERE USER = 'app_user' AND COMMAND = 'Sleep' AND TIME > 600;
复制结果执行——避免脚本循环自动 KILL，防止误伤。
为什么调大 max_connections 反而更危险
很多团队第一反应是把 max_connections 从 151 改成 1000，但没算内存账：
• 每个连接平均吃 4–8 MB 内存
• 1000 连接 ≈ 4–8 GB 额外内存开销
• 如果服务器总内存只有 16 GB，MySQL 很可能 OOM 被系统 kill
更隐蔽的问题是：wait_timeout 和 interactive_timeout 如果设得过大（比如 28800 秒 = 8 小时），Sleep 连接能挂一整天，根本不会释放。
生产建议值：
• wait_timeout 设为 300（5 分钟）
• interactive_timeout 设为 600（10 分钟）
• max_connections 按峰值 QPS × 平均响应时间 × 1.5 估算，别拍脑袋
