MySQL中经典的too many connection怎么破

2017 年 11 月 19 日 DBAplus社群 兰春

作者介绍

兰春，58安居客资深DBA，专注于MySQL领域的运维与运营。

一、什么是too many connection

1、重要参数

max_connections : The maximum permitted number of simultaneous client connections

允许的最大的链接数，如果超过这个数值，则会报：ERROR 1040 (HY000): Too many connections

max_user_connections: The maximum number of simultaneous connections permitted to any given MySQL user account

允许的每个用户最大链接数，如果超过这个数值，则会报： ERROR 1203 (42000): User dba already has more than 'max_user_connections' active connections。

一般这样的报错只会出现在业务机器上，并不会在DB server层报错，这样的话DBA就无法真正感知到错误，MySQL也非常贴心的推出了一个status供DBA查看：Connection_errors_max_connections

Connection_errors_max_connections : The number of connections refused because the server max_connections limit was reached.

细心的同学就会发现：那如果出现'max_user_connections' 的报错，就无法发现啦，这块目前我还没找到对应status。

二、什么情况下会发生too many connection

1、slow query 引起

2、sleep 空连接引起

三、实战案例

1、sleep 空链接引起的TMC（too many connection简称）

原因

由于代码没有主动及时的释放链接，那么在DB Server中存在大量的sleep链接，一旦超过max_connections则报错。

解决方案

（1）遇到这样的报错，如果没有及时解决，则会导致后面的业务都一直连不上数据库，影响面很大。

（2）所以我们第一件事情必须是保护数据库，kill掉这些sleep链接。关于kill这件事，又有很多技巧可以谈：

（3）完成上面几个步骤之后，只能保证你的数据库不会被压到，且你有机会登陆进去做一些管理事情，但要彻底解决还必须让业务方处理这些sleep链接。

（4）启用thread_pool功能可能可以解决这个问题，但是由于种种原因没有使用。

2、 slow query 引起的TMC

（1）先来说说真正的slow query

一般这种情况，也非常清晰明了，找到它，优化它，当然前提是你的数据库还活着。

我们通常有SQL防火墙保护，大大降低了这样的风险。预知SQL防火墙为何物，且听下回分享。

（2）伪装的slow query

好了，终于开始介绍这种最难的故障场景。

难点就是：因为它不是真正的slow，优化点难以寻找，所谓对症下药，就是要找到对应的症状，这也是难点所在。

废话不多说，这里介绍下前一段时间遇到的一次真实的案例。

故障症状

故障分析

重要参数详解

官方文档的解释我不多说，这里简单介绍下自己的理解。

innodb_thread_concurrency : 进入innodb存储引擎的线程数量，如果数量满了，就要排队
innodb_thread_sleep_delay : 排队等候进入innoDB的时候需要睡眠多长时间
innodb_adaptive_max_sleep_delay : 设置一个自适应的最大睡眠时间
innodb_concurrency_tickets: 一旦进入innoDB，就会获取一个票据tickets，在票据期间可以随意进入innoDB不需要排队，如果用完了，理论上则要排队（实测后发现并不是严格这套机制）