企业案例（一）:由于mysql sleep线程过多小故障

1、什么是长连接

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

通常的短连接操作步骤是：
连接-》数据传输-》关闭连接；
而长连接通常就是：
连接-》数据传输-》保持连接-》数据传输-》保持连接-》…………-》关闭连接；
这就要求长连接在没有数据通信时，定时发送数据包，以维持连接状态，短连接在没有数据传输时直接关闭就行了

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

长连接主要用于在少数客户端与服务端的频繁通信，因为这时候如果用短连接频繁通信常会发生Socket出错，并且频繁创建Socket连接也是对资源的浪费。
但是对于服务端来说，长连接也会耗费一定的资源，需要专门的线程（unix下可以用进程管理）来负责维护连接状态。
总之，长连接和短连接的选择要视情况而定。
首先，如果使用了长连接而长期没有对数据库进行任何操作，那么在timeout值后，mysql server就会关闭此连接，而客户端在执行查询的时候就会得到一个类似于“MySQL server has gone away“这样的错误。
在使用mysql_real_connect连接数据库之后，再使用mysql_options( &mysql, MYSQL_OPT_RECONNECT, … ) 来设置为自动重连。
这样当mysql连接丢失的时候，使用mysql_ping能够自动重连数据库。如果是在mysql 5.1.6之前，那么则应在每次执行完real_connect 之后执行mysql_options( &mysql, MYSQL_OPT_RECONNECT, … ) ,
如果是mysql 5.1.6+，则在connect之前执行一次就够了。

1.2、查看长连接

mysqladmin -uroot -p  processlist

实际的测试中我发现，当设置了MYSQL_OPT_RECONNECT为1时，超时后再查看processlist，则自动建立的连接不在列表中，但事实上连接确实建立并被使用了。
在MYSQL的默认设置中，如果一个数据库连接超过8小时没有使用(闲置8小时)，服务器将断开这条连接，后续在该连接上进行的查询操作都将失败。
网络上对该问题的描述非常多。也提供了相应的解决办法。我在这里提一些我自己的看法。

2、解决方法

2.1、方法一：修改mysql配置参数

道理非常简单，MYSQL的默认设置是在数据库连接超过8小时没有使用后将其断开，如果我们将这个时间改成更大的数值，那么连接超时所需的时间就会更长，
也就意味着更不容易超时。
网络上提供的修改方法一般是修改/etc/my.cnf，在这个文件中添加一行wait_timeout=你需要设置的超时时间 。实际上有一种比较简单的方法来修改这个参数：
首先作为超级用户登录到MYSQL，注意必须是超级用户，否则后面会提示没有修改权限。

然后输入
show global variables like 'wait_timeout';
回车执行后显示目前的超时时间：
+---------------+-------+

| Variable_name | Value |

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

| wait_timeout | 28800 |

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

1 row in set (0.00 sec)
上面显示的是默认的超时时间，即8个小时(单位是秒)。现在重新设置该参数，例如我们要将超时时间设置成10个小时，可以输入：
然后在配置文件里修改：
[mysqld]
interactive_timeout = 120  #<==此参数设置后wait_timeout自动生效。
wait_timeout = 120
回车执行，显示：
Query OK, 0 rows affected (0.00 sec)
表示设置成功，可以重新使用show global variables like 'wait_timeout'来验证。
这种方法比较直观，而且设置的参数立即生效。但如果/etc/my.cnf中没有配置，则重启服务后，global变量会从/etc/my.cnf中读取新的变量值。

2.2、 方法二：杀掉长连接进程

mysql> show processlist;
+----+------+-----------+------+---------+------+-------+------------------+
| Id | User | Host      | db   | Command | Time | State | Info             |
+----+------+-----------+------+---------+------+-------+------------------+
|  1 | root | localhost | NULL | Query   |    0 | init  | show processlist |
+----+------+-----------+------+---------+------+-------+------------------+
1 row in set (0.00 sec)
mysql> kill 212555221;

2.3、补充方法： 

# 在PHP程序中，不使用持久连接，即使用mysql_connetct而不是pconnect

# PHP程序执行完毕，应该显式调用mysql_close

#Java程序调整连接池（c3P0）或者调整Java服务（tomcat有关连接池参数）

# 逐步分析mysql的SQL查询及慢查询日志，找到查询过慢的sql,优化他。

关键词解释：

(1)interactive_timeout:
参数含义：服务器关闭交互式连接前等待活动的秒数。交互式客户端定义为在mysql_real_connect()中使用CLIENT_INTERACTIVE选项的客户端。
参数默认值：28800秒（8小时）
(2)wait_timeout:
参数含义：服务器关闭非交互连接之前等待活动的秒数。
在线程启动时，根据全局wait_timeout值或全局interactive_timeout值初始化会话wait_timeout值，取决于客户端类型(由mysql_real_connect()的连接选项CLIENT_INTERACTIVE定义)。
参数默认值：28800秒（8小时）
问题1：这里为什么要同时设置interactive_timeout,wait_timeout的设置才会生效？
答：    不设置interactive_timeout,wait_timeout也会生效。
问题2：interactive的值如果设置的和wait_timeout不同，为什么Interactive_timeout会覆盖wait_timeout?
答：在交互模式下(CLIENT_INTERACTIVE),interactive_timeout才生效，非交互模式下，不生效。
问题3：在进行MySQL优化时，因为interactive_timeout决定的是交互连接的时间长短，而wait_timeout决定的是非交互连接的时间长短。如果在进行连接配置时mysql_real_connect()最后一个参数client_flag不设置为CLIENT_INTERACTIVE，是不是interactive_timeout的值不会覆盖wait_timeout?
答：可以做实验试试。
问题4：为了减少长连接的数量，在设置优化时是不是可以将interactive_timeout的值设置的大些，而wait_timeout的值设置的小些？但是问题2的描述好像又不允许这样。。。
答：如2所述，在交互模式下，interactive_timeout取代wait_timeout。这样，如果有的客户端是交互模式方式连接mysql server。那么客户端的timeout受制于interactive_timeout。如果有的客户端是非交互模式，长连接mysql server。那么客户端的timeout受制于wait_timeout。(是否是交互模式的连接，由客户端决定)