這個問題是我之前遇到的，過了很久才想着去解決它，因為這也沒多大影響，無非就是再訪問一次的問題，后來有一次觀察網站的運行情況時，發現這個問題還挺嚴重，如果一直用，就不會出現問題，如果中間歇一會，再用就會提示數據查詢失敗，稍后重試，我之前還一直以為是偶爾的數據庫問題，這次發現絕對不是數據庫的問題，好了，開始着手解決。
大概找了一下規律，發現只要休息一會再次使用網頁查詢就會報錯，這個報錯是后端查詢數據庫失敗報的，那就看后端的代碼，反復看了好幾遍，發現沒有問題，那為什么會報錯呢，網上搜了一下，有人說是數據庫的timeout設置問題，我就去查看了一下數據庫的timeout數據，顯示如下：
這個數據很正常啊，怎么會導致幾分鍾后，連接就失效了呢？這里我后端是用python寫的，數據庫的連接使用的是SQLALchemy，SQLALchemy的重連機制在默認情況下是2個小時，這個也沒有問題，服務器上的代碼不便調試，於是我就在自己的虛擬機上調試一下，發現虛擬機上根本不會出現連接失敗的問題，兩邊的代碼是一樣的，唯一的區別就是數據庫不同，虛擬機使用的是本地的數據庫，服務器使用的是另一台服務器的數據庫，這時我意識到問題了，之前查詢的timeout是當前服務器的，而不是使用到的服務器的，查詢數據庫服務器的timeout發現數據也是正常的：
后來查詢global變量發現問題出現在這里，SHOW GLOBAL VARIABLES LIKE '%timeout';
這里的timeout和interactive_timeout都是100s，難怪會出現每過一段時間數據庫連接就中斷呢，后來詢問了同時這個參數設置的原因，好像是數據采集端使用的是labview寫的，為了防止占用太多的連接，所以將該值設置的很短，既然數據庫的設置不能改，那就改我們的代碼，SQLALchemy中有一項配置是來設置重連機制：SQLALCHEMY_POOL_RECYCLE,將該值設置為小於timeout的值即可，於是將SQLALCHEMY_POOL_RECYCLE = 90，重啟服務器的應用，問題解決了。
從這個問題看出，其實有時候一些報錯就是某個原因引起的，但是因為查詢的位置出錯，導致花費了很多額外的時間，就像這個，本來應該查數據庫服務器的信息，結果查的是應用服務器的信息（其實這兩個服務器的數據庫內容是一致的，我做的主從同步，一直想把查詢和增刪改的數據庫分開，這里還沒有分開，但是自己意識中錯誤的認為分開了）。