MySQL wait_timeout sleep

前段时间 现网突然频繁报出 连接不上数据库，偶滴的妖孽，其他地方都是用mysql，也没遇到这个问题呀。

在数据库服务器用 top 命令查看，1339 total   2 running   1337 sleeping

场景出现的理论依据
MySQL 的默认设置下，当一个连接的空闲时间超过8小时后，MySQL 就会断开该连接，而 c3p0/dbcp 连接池则以为该被断开的连接依然有效。在这种情况下，如果客户端代码向c3p0/dbcp 连接池请求连接的话，连接池就会把已经失效的连接返回给客户端，客户端在使用该失效连接的时候即抛出异常。

什么是长连接？

其实长连接是相对于通常的短连接而说的，也就是长时间保持客户端与服务端的连接状态。

通常的短连接操作步骤是：

连接-》数据传输-》关闭连接；

而长连接通常就是：

连接-》数据传输-》保持连接-》数据传输-》保持连接-》…………-》关闭连接；

这就要求长连接在没有数据通信时，定时发送数据包，以维持连接状态，短连接在没有数据传输时直接关闭就行了

什么时候用长连接，短连接？

长连接主要用于在少数客户端与服务端的频繁通信，因为这时候如果用短连接频繁通信常会发生Socket出错，并且频繁创建Socket连接也是对资源的浪费。

但是对于服务端来说，长连接也会耗费一定的资源，需要专门的线程（unix下可以用进程管理）来负责维护连接状态。

总之，长连接和短连接的选择要视情况而定。

首先，如果使用了长连接而长期没有对数据库进行任何操作，那么在timeout值后，mysql server就会关闭此连接，而客户端在执行查询的时候就会得到一个类似于“MySQL server has gone away“这样的错误。

在MYSQL的默认设置中，如果一个数据库连接超过8小时没有使用(闲置8小时)，服务器将断开这条连接，后续在该连接上进行的查询操作都将失败。

But 现实环境中需要你考虑的是：

1. 你设置多久检查一次连接有效的时间 依据是什么？
2. 默认加大/减小wait_timeout除了解决当前问题，会不会带来其他影响？

个人当前觉得此题 第一需考虑的是：
你业务当前高峰期mysql_connection是多少？保留多久connection在高峰期都不会撑爆你数据库连接池？
如果你知道这个池-那么是改mysql ？还是改c3p0？还是双管齐下都是有据可循且不会带来后遗症的-最佳解决方案

如我当前有环境，一个现网的后台管理系统，使用人数在50以内，那么我wait_timeout 就是默认8小时，c3p0不用做连接有效性检查等，都是万事ok的。

而我还有一个EPG前台管理系统，用户量在300万以内，如果我wait_timeout为8小时，那我一到高峰期肯定就是死翘翘的，会有太多的TCP连接没关闭，
数据库连接数肯定是不够的。
因EPG的一个访问-一次对数据库操作量不大，查询完数据就完成ok啦，wait_timeout 设置在120s内应该是够用啦，那么相对应的c3p0中 设置小于wait_timeout 的时间有效性检查 -就能确保获取到连接是有效的。

MySQL sleep进程连接过多原因分析

当php的页面执行结束时，会自动释放掉一切。相信很多人都跟我想的一样。但事实证明并不是这样。比如session就不会随着页面执行完毕而释放。

php的垃圾回收机制，其实只针对于php本身。对于mysql，php没权利去自动去释放它的东西。如果你在页面执行完毕前不调用mysql_close()，那么mysql那边是不会关闭这个连接的。如果你是用的是pconnect方式，即使你在页面执行完毕前调用mysql_close()，也无法另mysql关闭这个连接。

而另一些原因，框架或数据库包类特殊处理数据库连接，以便连接复用。

例如：使用yii 框架时，在执行完对应的数据库操作后，Yii2并不会调用yii2\db\Connection的close方法，只会调用yii2\db\Command中$this->pdoStatment->closeCursor()；以便能在当前连接上继续执行SQL。那么瞬时高并发的情况下，就会存在很多sleep连接。

mysql中睡眠连接会对mysql服务器造成影响

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

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

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

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

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

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

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

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

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

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

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

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

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

如设置：　

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