睡眠连接过多，会对mysql服务器造成什么影响？

睡眠连接过多，会对mysql服务器造成什么影响？ 严重消耗mysql服务器资源(主要是cpu, 内存)，并可能导致mysql崩溃。 造成睡眠连接过多的原因？ 1. 使用了太多持久连接（个人觉得，在高并发系统中，不适合使用持久连接） 2. 程序中，没有及时关闭mysql连接 3.

睡眠连接过多，会对mysql服务器造成什么影响？

严重消耗mysql服务器资源(主要是cpu, 内存)，并可能导致mysql崩溃。

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

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

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

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

那么，如果要从根本上解决sleep连接过多，就得从以上三点反复检查，但是见效并不快。

网上有人分享，使用shell脚本配合cron,定期杀死睡眠时间太久的连接，但是这种方法非常不可取，典型的以暴制暴，很可能导致数据崩溃，而且，还需要编写相应shell, 设置cron,　实施成本较繁琐，不推荐使用。

那么更好的办法应该是让mysql自己决定这些睡眠连接的命运，实施会更简单，有效。

mysql的配置文件中，有一项：

wait_timeout, 即可设置睡眠连接超时秒数，如果某个连接超时，会被mysql自然终止，多好的办法！

如设置：　

wait_timeout=100 #即设置mysql连接睡眠时间为100秒，任何sleep连接睡眠时间若超过100秒，将会被mysql服务自然终止，要比编写shell脚本更简单。

那么，对于正在运行中的生产服务器，在不能停止服务情况下，修改此项怎么办？很简单，以root用户登录到mysql,执行：

mysql> set global wait_timeout=10;

mysql> show global variables like 'wait_timeout';
+----------------------------+-------+
| Variable_name | Value |
+----------------------------+-------+
| wait_timeout | 10 |

+----------------------------+-------+

（这里一个容易把人搞蒙的地方是如果查询时使用的是show variables的话，会发现设置好像并没有生效，这是因为单纯使用show variables的话就等同于使用的是show session variables，查询的是会话变量，只有使用show global variables，查询的才是全局变量。
网络上很多人都抱怨说他们set global之后使用show variables查询没有发现改变，原因就在于混淆了会话变量和全局变量，如果仅仅想修改会话变量的话，可以使用类似set wait_timeout=10;或者set session wait_timeout=10;这样的语法。）

在我的生产环境中，使用这个办法，取得了相当好的效果。

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

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

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

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

MYSQL数据库安装完成后，默认
最大连接数是100，一般流量稍微大一点的论坛或网站
这个连接数是远远不够的，增加默认MYSQL连接数的方法有两个
方法一：进入MYSQL安装目录 打开MYSQL配置文件 my.ini 或 my.cnf查找 max_connections=100 修改为 max_connections=1000 服务里重起MYSQL即可
方法二：MySQL的最大连接数默认是100客户端登录：mysql -uusername -ppassword
设置新的最大连接数为200：mysql> set GLOBAL max_connections=999
显示当前运行的Query：mysql> show processlist
显示当前状态：mysql> show status
退出客户端：mysql> exit

查看设置最大数：mysql> show variables like 'max_connections';