wait_timeout 过大有弊端，其体现就是 MySQL 里大量的 SLEEP 进程无法及时释放，拖累系统性能，不过也不能把这个指设置的过小，否则你可 能会遭遇到“MySQL has gone away”之类的问题。
配置
如果你没有修改过 MySQL 的配置，缺省情况下，wait_timeout 的初始值是 28800。
通常来说，我觉得把 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 '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;这样的语法。
另一个值得注意的是会话变量wait_timeout初始化的问题，这一点在手册里已经明确指出了，我就直接拷贝了：
On thread startup, the session wait_timeout value is initialized from the global wait_timeout value or from the global interactive_timeout value, depending on the type of client (as defined by the CLIENT_INTERACTIVE connect option to mysql_real_connect()).
MySQL 大拿 Jeremy Zawodny 曾在他的文章 Fixing Poor MySQL Default Configuration Values 里面列出了几个很恶心的 MySQL 缺省设置，不过没包含 wait_timeout，但我觉得它也应该算一个，每次新装 MySQL 后最好都记得修改它。