1. 当MySQL突然报Too many connections时凌晨3点15分监控系统突然报警你的MySQL数据库抛出了ERROR 1040 (HY000): Too many connections错误。这个瞬间所有依赖这个数据库的业务系统开始出现连接失败用户投诉电话瞬间被打爆。作为DBA或者运维人员此刻最需要的是快速止血然后才是排查根因。Too many connections错误意味着当前MySQL实例的所有可用连接都被占用了新的连接请求无法建立。MySQL默认的最大连接数(max_connections)通常是151不同版本可能略有差异当Threads_connected达到这个值时就会触发这个错误。2. 30秒紧急止血方案2.1 立即增加最大连接数临时方案最快的方式是通过超级用户连接通常需要预留一个管理员连接执行SET GLOBAL max_connections 500;这个命令会立即生效无需重启MySQL服务。将连接数临时调大可以快速恢复业务但要注意警告这只是临时解决方案盲目增加max_connections可能导致服务器资源耗尽特别是内存不足时会引发更严重的问题。2.2 释放空闲连接同时可以清理长时间空闲的连接-- 查看所有连接及其状态 SHOW PROCESSLIST; -- 终止特定连接替换ID为实际连接ID KILL CONNECTION [connection_id]; -- 批量终止空闲超过10分钟的连接 SELECT CONCAT(KILL ,id,;) FROM information_schema.processlist WHERE Command Sleep AND Time 600 INTO OUTFILE /tmp/kill_idle.sql; SOURCE /tmp/kill_idle.sql;2.3 使用连接池管理如果应用使用了连接池如HikariCP、Druid等可以临时调整连接池参数# HikariCP示例 spring.datasource.hikari.maximum-pool-size50 spring.datasource.hikari.minimum-idle103. 3分钟根因定位方法3.1 检查当前连接状态-- 查看当前连接数 SHOW STATUS LIKE Threads_connected; -- 查看最大连接数设置 SHOW VARIABLES LIKE max_connections; -- 查看连接来源分布 SELECT user, host, COUNT(*) as connections FROM information_schema.processlist GROUP BY user, host ORDER BY connections DESC;3.2 分析连接泄漏-- 查看长时间运行的查询 SELECT * FROM information_schema.processlist WHERE TIME 60 ORDER BY TIME DESC; -- 检查没有提交的事务 SELECT * FROM information_schema.innodb_trx WHERE TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) 60;3.3 检查应用连接管理常见问题包括应用获取连接后未正确关闭连接池配置不合理最大连接数过大事务未提交或回滚长查询或锁等待4. 长期解决方案4.1 合理设置max_connections计算建议值max_connections (可用内存 - 系统预留) / 每个连接所需内存MySQL 8.0每个线程约需要4-12MB内存取决于配置。例如8GB内存的服务器-- 永久修改需重启生效 SET PERSIST max_connections 300;4.2 优化连接池配置推荐配置原则连接池最大大小不超过max_connections的70%最小空闲连接根据业务波谷设置添加连接验证查询设置合理的超时时间# Druid示例 spring.datasource.druid.max-active100 spring.datasource.druid.initial-size10 spring.datasource.druid.min-idle10 spring.datasource.druid.max-wait60000 spring.datasource.druid.validation-querySELECT 1 spring.datasource.druid.test-while-idletrue4.3 实施连接监控-- 创建监控视图 CREATE VIEW connection_monitor AS SELECT EVENT_TIME, VARIABLE_VALUE as connections FROM performance_schema.global_status WHERE VARIABLE_NAME Threads_connected;配合Prometheus Grafana设置警报阈值如80% max_connections。5. 高级排查技巧5.1 使用performance_schema深入分析-- 启用连接追踪 UPDATE performance_schema.setup_consumers SET ENABLED YES WHERE NAME LIKE events_waits%; -- 查看连接等待事件 SELECT * FROM performance_schema.events_waits_current WHERE EVENT_NAME LIKE wait/io/socket%;5.2 分析连接风暴模式当出现周期性连接暴增时可以检查应用日志对应时间点的请求分析是否有定时任务未使用连接池检查是否有重试机制导致雪崩5.3 连接代理中间件对于大规模应用考虑使用ProxySQL或MySQL Router管理连接# ProxySQL配置示例 INSERT INTO mysql_servers(hostgroup_id,hostname,port) VALUES (10,mysql-master,3306); INSERT INTO mysql_users(username,password,default_hostgroup) VALUES (app_user,password,10); LOAD MYSQL SERVERS TO RUNTIME; SAVE MYSQL SERVERS TO DISK;6. 预防措施与最佳实践代码审查确保所有数据库访问都使用try-with-resources或类似机制连接池监控监控连接池活跃连接、等待线程等指标定期维护每月检查max_connections设置是否仍合适故障演练模拟连接泄漏场景测试系统恢复能力架构优化考虑读写分离减少主库连接压力我在实际运维中总结的经验是连接数问题往往不是数据库问题而是应用问题。90%的Too many connections案例最终都能追溯到应用代码中的连接泄漏或不当管理。建立完善的连接监控和告警机制能在问题扩大前及时发现并处理。