用ci開發了一個網站，發現mysql經常提示連接數過多，登陸mysql，用show processlist發現很多sleep的進程，原理是在application/config/database.php中設置了$db['default']['pconnect'] = TRUE;在mysql中用show global variables like 'wait_timeout'；顯示wait_timeout=28800。原來是在ci中開了pconnect,且在mysql中wait_timeout爲默認值28800，導致MySQL裏大量的SLEEP進程無法及時釋放，拖累系統性能。
關於sleep進程過多的文章。http://blog.163.com/sujoe_2006/blog/static/33531512011521113038227/
如果你沒有修改過MySQL的配置，缺省情況下，wait_timeout的初始值是28800。
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 '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後最好都記得修改它。
參考文章2
睡眠連接過多，會對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,執行：
set global wait_timeout=100
即可。
在我的生產環境中，使用這個辦法，取得了相當好的效果。
當然，更根本的方法，還是從以上三點排查之：
1. 程序中，不使用持久鏈接，即使用mysql_connect而不是pconnect。
2. 程序執行完畢，應該顯式調用mysql_close
3. 只能逐步分析系統的SQL查詢，找到查詢過慢的SQL,優化之