最近线上遇到一个问题，接口日志发现有很多超时报错，根据日志定位到数据库实例之后发现一切正常，一般来说接口出现超时排查顺序如下：

慢查询 -》连接数 -》 服务器负载 -》网卡流量，但是这次从QPS、连接数、服务器负载、IO消耗、响应时间及慢查询上都非常正常并没有什么异常发生，只有如下这个图有变化。

在排除了前端服务器没有出现异常后，看来问题就出现在这个链接数变化上面了。为了看懂上面的图我们先说一下状态值的含义。

1、Max Connections和Max Used Connection

这两个就不细说了，分别是最大链接数限制和每个用户最大链接数限制。

2、Aborted Clients：

The number of connections that were aborted because the client died without closing the connection properly.

当ablort clients增大的时候意味着有客户端成功建立连接，但是很快就断开连接或者被终止了，这种情况一般发生在网络不稳定的环境中。主要的可能性有

a)客户端没有主动关闭mysql连接mysql_close()。

b)wait_timeout设置很短被mysql干掉了。

c)客户端由于某些原因被干掉了。

3、Aborted Connection：

The number of failed attempts to connect to the MySQL server.

当有大量的链接连接不上mysql的时候，这个数值就会激增。主要的可能有：

a)没有授权或者密码不对。一般错误日志中会有如下报错( Access denied for ‘user’@‘host’ )

b)连接数满了。一般报错包含(too many connections)

c)超过链接时间限制，主要有这个参数控制connect_timeout(mysql默认是10s，基本除非网络环境极端不好，一般不会超时。)

4、Threads Connected：

The number of currently open connections.

也就是我们经常使用show processlist看见那个数值。

5、Connections

The number of connection attempts (successful or not) to the MySQL server.

所有尝试连接到mysql server的连接数，关键时不管成功还是失败。所以这个数值的增量并不等于show processlist的数值，这点需要注意。

了解以上参数之后，就可以分析这个图了，首先第一反应时连接数有增加，我们可以看到connections和thread connected都增加了，但是没有达到max connections的限制。

在仔细看图下的数据，我们发现abort connection和connections的max值和avg值基本一样，在仔细看图，可以发现蓝线和绿线基本重合了。

从上述参数含义看，在问题时间段所有尝试建立的链接都失败了，导致connections和abort connection同步增加完全重叠。

但是究竟是什么导致链接数上升，前端开始重建链接，由于当时的前端日志没有及时分析出来，故我们就不得而知了。但是有3个怀疑点：

1、由于mysql版本是5.5.12，所以可能遇到了max_connections的bug，可以见这个blog(http://www.cnblogs.com/billyxp/p/3408335.html)，这种情况下，前端日志应该有非常多的too many connection是的报错。

2、短时间内有大量的大包传输，导致超过max_allow_packet的限制，导致断开连接。这个设置在server和client上都有，需要同步配置。同时前端应该报 Got a packet bigger than ‘max_ allowed__packet ’ bytes这个报错。

3、超过max_connect_error的限制，导致某一个ip出现问题，不停的重试。(这个可能是最不可能，首先默认数值非常大，其次单个ip不应该出现这么大的影响。max_connect_error代表某一个ip连续失败超过n之后，server会拒绝这个ip的请求，只有flush host cache才可以解封。)