MySQL服务器的线程数需要在一个合理的范围之内，这样才能保证MySQL服务器健康平稳地运行。Threads_created表示创建过的线程数，通过查看Threads_created就可以查看MySQL服务器的进程状态。

1. mysql> show global status like 'Thread%';  
2. +-------------------+-------+  
3. | Variable_name | Value |  
4. +-------------------+-------+  
5. | Threads_cached | 46 |  
6. | Threads_connected | 2 |  
7. | Threads_created | 570 |  
8. | Threads_running | 1 |  
9. +-------------------+-------+ 

如果我们在MySQL服务器配置文件中设置了thread_cache_size，当客户端断开之后，服务器处理此客户的线程将会缓存起来以响应下一个客户而不是销毁(前提是缓存数未达上限)。

Threads_created表示创建过的线程数，如果发现Threads_created值过大的话，表明MySQL服务器一直在创建线程，这也是比较耗资源，可以适当增加配置文件中thread_cache_size值，服务器
thread_cache_size配置：

1. > show variables like 'thread_cache_size';  
2. +-------------------+-------+  
3. | Variable_name | Value |  
4. +-------------------+-------+  
5. | thread_cache_size | 64 |  
6. +-------------------+-------+ 

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

　　慢查询 -》连接数 -》 服务器负载 -》网卡流量，但是这次从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才可以解封。）