对付 MySQL 的死连接，Sleep的进程的来源探究

重的。如果发现你的mysql 有很多死连接存在，首先要先检查你的程序是否使用的是pconnect的方式，其次，检查在页面执行完毕前是否及时调用了mysql _close()，  还有一个办法，你可以在my.cnf里面加上wait_timeout和interactive_timeout，把他们的值设的小一些 ，默认情况下wait_timeout的值是8小时的时间，你可以改成1个小时，或半个小时。这样mysql 会更快的杀死死连接。防止连接总数超过max_connection的值。或者把max_connection的值设置的更大，不过这样显然不妥，连接的数量越多，对你服务器的压力越大。实际上那些连接都是冗余的，把它们尽快杀死才是上策。 以前总是说，在使用php连接mysql 的时候，尽量不要使用pconnect的方式，看完我上面所说的那些，应该可以明白为什么了吧，因为我们使用php大多数情况下都是做web 开发，web开发是面向多用户，那么用户的数量与mysql 连接数是成正比的。使用pconnect的方式，即使你的调用mysql _close()也是无法释放数据库 连接的，那么mysql 中的死连接的数量就会越来越多了。 我认为，只有当你的应用 属于那种点对点方式，或者你能保证连接数量很少的情况，才有必要去采用pconnect的方式，因为连接数量少，那么让它一直处于连接状态，避免了重复打开关闭的过程。这样可能会比传统方式更好一些。 至于何时该去调用mysql _close()，最正确的做法是如果下面不再执行mysql 的操作了，在你上一次执行完mysql 操作后，立刻就调用mysql _close()。这才是最正确的做法，并不是总要把mysql _close()写在页面最后一行就可以了。 如果你没有修改过MySQL 的配置，缺省情况下，wait_timeout的初始值是。 wait_timeout过大有弊端，其体现就是MySQL 里大量的SLEEP进程无法及时释放，拖累系统性能，不过也不能把这个指设置的过小，否则你可能会遭遇到“MySQL has gone away”之类的问题 ，通常来说，我觉得把wait_timeout设置为10是个不错的选择，但某些情况下可能也会出问题 ，比如说有一个CRON脚本，其中两次SQL查询的间隔时间大于10秒的话，那么这个设置就有问题 了（当然，这也不是不能解决的问题 ，你可以在程序里时不时mysql _ping一下，以便服务器知道你还活着，重新计算wait_timeout时间）： # vi /etc/my.cnf [mysqld] wait_timeout=10 # /etc/init.d/mysql restart复制代码不过这个方法 太升硬了，线上服务重启无论如何 都应该尽可能避免，看看如何在MySQL 命令行里通过SET来设置： mysql > set global wait_timeout=10; mysql > show global variables like '%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;这样的语法。 另一个值得注意的是会话变量wait_timeout初始化的问题 ，这一点在手策腼已经明确指出了，我就直接拷贝了：On thread startup the session wait_timeout value is initialized from the global wait_timeout value or from