發現存在大量TIME_WAIT狀態的連接
tcp 0 0 127.0.0.1:3306 127.0.0.1:41378 TIME_WAIT
tcp 0 0 127.0.0.1:3306 127.0.0.1:41379 TIME_WAIT
tcp 0 0 127.0.0.1:3306 127.0.0.1:39352 TIME_WAIT
tcp 0 0 127.0.0.1:3306 127.0.0.1:39350 TIME_WAIT
tcp 0 0 127.0.0.1:3306 127.0.0.1:35763 TIME_WAIT
tcp 0 0 127.0.0.1:3306 127.0.0.1:39372 TIME_WAIT
tcp 0 0 127.0.0.1:3306 127.0.0.1:39373 TIME_WAIT
tcp 0 0 127.0.0.1:3306 127.0.0.1:41176 TIME_WAIT
通過調整內核參數解決
vi /etc/sysctl.conf
編輯文件，加入以下內容：
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 30
然后執行/sbin/sysctl -p讓參數生效。
net.ipv4.tcp_syncookies = 1表示開啟SYN Cookies。當出現SYN等待隊列溢出時，啟用cookies來處理，可防范少量SYN攻擊，默認為0，表示關閉；
net.ipv4.tcp_tw_reuse = 1表示開啟重用。允許將TIME-WAIT sockets重新用於新的TCP連接，默認為0，表示關閉；
net.ipv4.tcp_tw_recycle = 1表示開啟TCP連接中TIME-WAIT sockets的快速回收，默認為0，表示關閉。
net.ipv4.tcp_fin_timeout修改系統默認的TIMEOUT時間
修改之后，再用命令查看TIME_WAIT連接數
netstat -ae|grep “TIME_WAIT” |wc –l
發現大量的TIME_WAIT 已不存在，mysql進程的占用率很快就降下來的，網站訪問正常。
不過很多時候，出現大量的TIME_WAIT狀態的連接，往往是因為網站程序代碼中沒有使用mysql.colse()，才導致大量的mysql TIME_WAIT.
如果你的服務器是Windows平台，可以修改下面的注冊表鍵值：
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"TcpTimedWaitDelay"=dword:0000001e
此值是TIME_WAIT狀態的最長時間。缺省為240秒，最低為30秒，最高為300秒。建議為30秒。
注釋：
（
1，TCP結束的過程如下:
Server Client
-------------- FIN --------------> server: fin_wait_1
<------------- ACK --------------- client: close_wait server:fin_wait_2
<------------- FIN --------------- client發出fin之后就關閉
-------------- ACK -------------> server發出ack后進入time_wait狀態
Time_Wait的默認時間是2倍的MLS，就是240秒鍾。MLS是TCP片在網上的最長存活時間。
TIME_Wait的主要作用是保證關閉的TCP端口不立即被使用。因為當網絡存在延遲時，可能當某個端口被關閉后，網絡中還有一些重傳的TCP片在發向這個端口，如果這個端口立即建立新的TCP連接，則可能會有影響。所以使用2倍的MSL時間來限制這個端口立即被使用。
現在的問題在於，4分鍾的時間有點長。
因此，Time_wait的影響，我想，首先每個TCP連接都各自有個數據結構，叫TCP Control Block.Time_wait的時候這個數據結構沒有被釋放。所以當有太多的TCP連接時，內存可能會被占用很多。
2，To ValorZ：TIME_WAIT狀態也稱為2MSL等待狀態，而不是2MLS，筆誤吧！
每個TCP報文在網絡內的最長時間，就稱為MSL（Maximum Segment Lifetime），它的作用和IP數據包的TTL類似。
RFC793指出，MSL的值是2分鍾，但是在實際的實現中，常用的值有以下三種：30秒，1分鍾，2分鍾。
注意一個問題，進入TIME_WAIT狀態的一般情況下是客戶端，大多數服務器端一般執行被動關閉，不會進入TIME_WAIT狀態，當在服務器端關閉某個服務再重新啟動時，它是會進入TIME_WAIT狀態的。
舉例：
1.客戶端連接服務器的80服務，這時客戶端會啟用一個本地的端口訪問服務器的80，訪問完成后關閉此連接，立刻再次訪問服務器的80，這時客戶端會啟用另一個本地的端口，而不是剛才使用的那個本地端口。原因就是剛才的那個連接還處於TIME_WAIT狀態。
2.客戶端連接服務器的80服務，這時服務器關閉80端口，立即再次重啟80端口的服務，這時可能不會成功啟動，原因也是服務器的連接還處於TIME_WAIT狀態。
windows
TcpTimedWaitDelay和MaxUserPort設置
描述：確定 TCP/IP 可釋放已關閉連接並重用其資源前，必須經過的時間。
關閉和釋放之間的此時間間隔通稱 TIME_WAIT 狀態或兩倍最大段生命周期（2MSL）狀態。
此時間期間，重新打開到客戶機和服務器的連接的成本少於建立新連接。
減少此條目的值允許 TCP/IP 更快地釋放已關閉的連接，為新連接提供更多資源。如果運行的應用程序需要快速釋放和創建新連接，而且由於 TIME_WAIT 中存在很多連接，導致低吞吐量，則調整此參數。
如何查看或設置： 使用 regedit 命令訪問 HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/ Services/TCPIP/Parameters 注冊表子鍵並創建名為 TcpTimedWaitDelay 的新 REG_DWORD 值。
將此值設置為十進制 30，其為十六進制 0x0000001e。
該值將等待時間設置為 30 秒。
停止並重新啟動系統。 缺省值：0xF0，它將等待時間設置為 240 秒（4 分鍾）。
建議值：最小值為 0x1E，它將等待時間設置為 30 秒。
MaxUserPort 描述：確定在應用程序從系統請求可用用戶端口時，TCP/IP 可指定的最高端口號。
如何查看或設置： 使用 regedit 命令訪問 HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/ Services/TCPIP/Parameters 注冊表子鍵並創建名為 MaxUserPort 的新 REG_DWORD 值。
停止並重新啟動系統。
缺省值：無 建議值：至少十進制 32768。
注：當在 Windows NT 或 Windows 2000 操作系統上調整 WebSphere Application Server 時，同時使用這兩個參數。
***如不能恢復*****
1找研發排查下這種情況是不是程序上的bug，短連接存在一定缺陷，后端同事建議您使用長連接
2.在web的主機上配置tcp快速回收機制，具體配置需要您那邊對業務做出評估。
3.是否存在慢查詢語句，做出優化