今天收到运维同事短信，说有个线上业务"可能是数据库DB堵塞了，导致mysql链接过多，让我看一下"。

回家后赶紧用家里vpn登录数据库服务器，show processlist

看了以下，发现我的那个业务的DB确实有很多sleep链接没有关闭。

以前也曾遇到过类似的问题，导致此问题的原因从网上查了，大体有几下几种原因：

造成睡眠连接过多的原因？

1.　使用了太多持久连接(个人觉得，在高并发系统中，不适合使用持久连接)

2.　程序中，没有及时关闭mysql连接

3.　数据库查询不够优化，过度耗时。

当然，更根本的方法，还是从以上三点排查之：

1.　程序中，不使用持久链接，即使用mysql_connect而不是pconnect。

2. 程序执行完毕，应该显式调用mysql_close

3.　只能逐步分析系统的SQL查询，找到查询过慢的SQL,优化之p

我是用排除法去定位问题，对于此原因，1和3通过分析，发现根本不满足

此处先排除是mysql 配置的问题，sleep的关闭时间是8个小时，默认值(show variables like

'wait_timeout';)，并且服务器配置都是运维人员维护，我们的运维还是很出色的

排除1：

我的业务，php链接mysql并没有使用持久链接 mysql_pconnect,高并发系统框架中，都不会用持久链接的

排除3：

数据库查询不够优化？自己写的，不能够。如果真的有不够不够优化的sql，可以开启mysql慢查询日志查看，并优化之；还有一点就是我的这个业务通过看数据库昨日、今日两天的访问情况，读写都不是很多，表的数据量只有二百多万条，而且已经线上正常运营了很久，假如有不够优化的查询，早就挂了。

那问题只有可能是 2 程序中，没有及时关闭mysql连接，造成这个问题的原因很多，也很难分析。一般只要是框架里，都会即时关闭mysql链接的(mysql_close),页面访问完，mysql链接必然会自动关闭，比较可信的原因如下：

【减少MySQL的Sleep进程有效方法】

经常遇到很多朋友问到，他的MySQL中有很多Sleep进程，严重占用MySQL的资源，现在分析一下出现这种现象的原因和解决办法：

1，通常来说，MySQL出现大量Sleep进程是因为采用的PHP的MySQL长链接数据库方式，即使用了mysql_pconnect来打开链接数据库，解决办法就是使用“短”链接，即mysql_connect函数。

2，在使用mysql_connect短链接方式打开数据库，每个页面在打开数据库后，执行SQL完成，当页面脚本结束的时候，这个MySQL连接会自动关闭并且释放内存。但仍然出现大量Sleep进程，可以看看网站是否存在以下几个方面的问题。

A，硬盘上存在大量的静态文件，或者WEB服务器负荷太重，在处理HTTP请求响应变得太慢，这样也有可能导致出现大量Sleep进程，解决方法适当调整WEB服务参数和文件，一味的静态或者缓存化网页内容并不是灵丹妙药。

B，在网页脚本中，有些计算和应用可能非常耗时，比如在0秒的时候打开数据库执行完一段SQL代码后，网页脚本随即花了20秒钟进行一段复杂的运算，或者

是require了一个庞大的PHP文件(比如含有几千个违规关键字的过滤函数)，哪么这个时候在MySQL后台看到的进程中，这个20秒的过程

MySQL并没有做任何事情了，一直处于Sleep状态，直到这个页面执行完毕或者达到wait_timeout值(被强行关闭)，优化网页脚本，尽量让

程序快速运行，或者在执行这段耗时的运行过程中，执行mysql_close把当前MySQL链接强行关闭。

C，在采集站中，MySQL中大量的Sleep进程这类现象尤其明显(比如很多网友问道DeDeCMS的MySQL中出现大量Sleep)，因为大部的采

集器页面在运行过程中，事先打开了一个MySQL链接(可能是为了验证用户权限等)，然后开始使用file_get_contents之类的操作去获取一

个远程的网页内容，如果这个远程的站点访问速度太慢，比如花了10秒时间才把网页取回，哪么当前采集脚本程序就一直阻塞在这里，并且MySQL啥事也没

干，一直处于Sleep状态。解决方法同上，在发出file_get_contents采集远程网页的时候，使用mysql_close强行关闭

MySQL的连接，等采集完成在适当需要的时候再重新mysql_connect即可。

总的说来，MySQL是一个非常高效快速的数据库，要让他发挥到最大的性能，同时也不要过量的去掘取他的优势所在，适当的分表(超过10G的表，在打开和关闭以前更新的时候效率明显下降很多)，尽可能的优化SQL都可以做到事半功倍的。

通过分析，发现我的业务的问题和上面的B、C问题类似，但问题真的没有完全一样的，这个要根据自己的业务分析。我得问题最后定位在一个后台的服务出问题了，有个验证服务，每次登录都会去验证，但此服务失败了，导致页面响应超时，我想应该是进程中断了，最终导致mysql无法正常关闭，从而产生了大量的sleep，严重消耗mysql服务器资源(主要是cpu,

内存)，并可能导致mysql崩溃。

解决问题的方法很多：恢复业务；kill掉sleep的进程，修改sleep时间为60秒，60秒后sleep的链接会自动释放掉的；重启mysql(慎用)