mysql突然無法連接,mysql連接出現1045錯誤 _為什么軟件關閉數據庫連接

前言最近遇到在將本地的項目部署到服務器上之后遇到的一個奇怪問題
在部署完成后，網站當時可以正常工作，但是第二天訪問網站的時候卻會遇到一個500 Server Error 。
從日志中可以看出是MySQL數據庫出現了異常

文章插圖
翻譯如下:
最后一個數據包在 83827560 ms 之前被成功接收，最后一個數據包在83827560 ms 之前被成功發送。比服務的配置參數wait_timeout的值要長。
日志中給出的建議如下

文章插圖
翻譯如下：
你應考慮在程序中進行數據庫操作之前檢驗數據庫連接的有效性或者將數據庫的autoReconnect屬性設置為true來避免這個問題
關于wait_timeout和autoReconnect下面我們會依次分析介紹！
原因分析我們進入mysql的命令行查詢超時時間

文章插圖
28800單位是秒轉化成小時就是8小時
看出MySQL的默認設置，當一個連接的空閑時間超過8小時后，MySQL就會斷開該連接
所以發現問題出在如果超過這個wait_timeout時間(默認是8小時)對數據庫沒有任何操作，那么MySQL會自動關閉數據庫連接以節省資源
數據庫連接自動斷開的問題確實是在第二天發生了，也就是在一個晚上沒有對數據庫進行操作(顯然超過了8小時)的情況下發生的這個問題

文章插圖
大家用命令show processlist; 可以查看Sleep狀態的進程Sleep，同時可以看到每個進程Sleep多久了：

文章插圖
下面介紹下解決和優化辦法！
解決方法1.autoReconnect這個參數表示在mysql超時斷開連接后會自動重新連接
配置的話，只需要在連接mysql的語句寫上autoReconnect=true
jdbc:mysql://127.0.0.1:3306/stock_tweet?autoReconnect=true 下面是MySQL官網對autoReconnect的解釋:

文章插圖
同時可以看到官網不推薦使用這個參數，因為它有一些副作用
具體介紹下：
原有連接上的事務將會被回滾，事務的提交模式將會丟失原有連接持有的表的鎖將會全部釋放原有連接關聯的會話Session將會丟失，重新恢復的連接關聯的將會是一個新的會話Session原有連接定義的用戶變量將會丟失原有連接定義的預編譯SQL將會丟失原有連接失效，新的連接恢復后，MySQL將會使用新的記錄行來存儲連接中的性能數據2.修改配置涉及到兩個配置參數interactive_timeout和wait_timeout
wait_timeout 指的是mysql在關閉一個非交互的連接之前所要等待的秒數
interactive_time 指的是mysql在關閉一個交互的連接之前所要等待的秒數
對于交互和非交互連接，說得直白一點就是，通過mysql客戶端連接數據庫是交互式連接，通過jdbc連接數據庫是非交互式連接。
配置方法：
1.會話方式
msyql> set global wait_timeout=2880000;msyql> set global interactive_timeout=2880000;這種方式只對當前會話生效
2.修改配置文件方式
修改/etc/my.cnf文件，在 [mysqld] 節中設置：

文章插圖
之后再重啟下服務器就好了
注意：
將wait_timeout這個值設置得大了，可能會導致空閑連接過多。
如果你的MySQL Server有大量的閑置連接，他們不僅會白白消耗內存，而且如果連接一直在累加而不斷開，最終肯定會達到MySQL Server的連接上限數，這會報'too many connections'的錯誤。