MySQL频繁报错Too many connections重启后临时恢复如何解决

问题核心信息 #

报错内容：创建数据库连接失败，服务端返回 Too many connections
相关运行参数：max_connections=512，max_used_connections=468，Threads_connected=90，Processlist=90
复现特征：进程列表内除1个活跃连接外，其余均为sleep模式，报错定期触发，重启MySQL可临时恢复，运行一段时间后再次出现。

定位步骤 #

• 核对所有接入业务的连接池总配额：统计所有业务服务、定时脚本、中间件的连接池最大连接数总和，确认是否超过MySQL的max_connections阈值，多服务连接池配额叠加后超过上限是最常见诱因。
• 排查应用端连接泄漏：检查业务代码是否存在异常分支未关闭连接、事务未正确提交/回滚的情况，连接使用后未主动释放会导致连接长期处于sleep状态占用名额。
• 检查MySQL闲置连接回收配置：执行命令show variables like '%timeout%'查看wait_timeout和interactive_timeout参数值，默认配置为8小时，配置过长会导致sleep连接长期无法被自动回收。
• 排查非业务端隐形连接占用：确认监控采集程序、数据同步脚本、定时任务等边缘场景是否存在频繁新建长连接、未复用也未释放的逻辑，这类连接会逐步累积耗尽连接数。

解决方案 #

• 短期临时修复：无需重启MySQL，执行命令set global max_connections = 1024;临时调大最大连接数上限（需结合服务器内存配置，单个MySQL连接约占用2M内存，避免调得过高引发内存溢出），同时手动kill闲置超过24小时的sleep连接快速释放资源。
• 中长期彻底修复：
  • 优化应用连接池配置：控制单个服务连接池最大连接数在10~50区间，所有接入端的总最大连接数不超过MySQL max_connections的80%，同时开启连接池的闲置连接自动回收功能，配置合理的闲置超时阈值。
  • 修复代码连接泄漏：使用语言自带的自动资源管理语法（如Java的try-with-resources、Python的with上下文管理器）托管连接释放逻辑，补全异常场景下的连接关闭、事务回滚逻辑，确保连接使用完后及时归还连接池。
  • 调整MySQL自动回收参数：将wait_timeout和interactive_timeout调整为30分钟到2小时的合理区间，执行命令set global wait_timeout = 1800; set global interactive_timeout = 1800;即时生效，同时修改my.cnf/my.ini配置文件确保重启后配置不丢失。
  • 统一边缘场景连接管理：所有定时任务、中间件、第三方脚本的数据库连接统一接入公共连接池，禁止无限制新建独立连接。

内容的提问来源于stack exchange，提问作者Venu pedduri