最近线上遇到一个问题，接口日志发现有很多超时报错，根据日志定位到数据库实例之后发现一切正常，一般来说接口出现超时排查顺序如下：
慢查询 -》连接数 -》 服务器负载 -》网卡流量，但是这次从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才可以解封。）