最近剛從一家人力資源公司離職，至一家醫療器械公司擔任軟件軟件開發工作，目前主要工作基本以爲不同醫院開發並配合實施部署定製化平臺，現將最近在公司遇到的問題和解決問題的思路做一次簡單的整理，一是方便今後查漏補缺，二是與大家分享一下，交流交流意見!
項目的交互形式是：終端設備將實時監控數據數據傳輸到雲服務器，然後醫院的定製化系統再每隔10秒鐘從雲服務器拉取雲服務其中未被前置機拉取過的數據，存放在醫院的定製化數據庫中。遇到的問題是：其中一家醫院運行一段時間（大概一兩天左右），經常出現有一到兩個小時取不到數據，隔了一到兩個小時，系統恢復正常。
遇到這種問題，一般先排查網絡層的原因，先查看log日誌，發現問題時段一直報雲數據庫連接超時，我就從醫院前置機（部署定製化的服務器）分別ping雲服務器IP和百度首頁IP地址,一天後對比發現ping雲服務器與百度的數據相差不大，基本在30ms-50ms之間，平均40ms左右,沒有丟包，但中間出了一個狀況：ping雲服務器的時候出現了最長連接168ms,所以網絡問題既不能確定，也不能完全排除。
然後我又遠程到醫院前置機，隔段時間查看一次，終於找到了問題時段，立馬telnet雲服務器數據庫端口，發現端口是通的，所以網絡問題算是排除掉了！
那麼問題只能出現在程序和數據庫了，於是我登錄到數據庫，發現有時能登陸，有時登錄不上，但是邏輯又說不通，因爲醫院的前置機是在一段時間內一直連接不上，所以暫時先以這個方式解決：增大數據庫連接超時時長，同時排查其它問題。
增大數據庫連接超時時長後發現問題出現的比之前更加頻繁，由原來的一兩天出現一次加速爲幾個小時出現了一次，所以這個方向也是錯誤的，在這個過程中我注意到，雖然打印的是數據庫連接超時，但報錯的顯示行號並沒有在數據庫連接所在行，而是在sql查詢所在行，所以問題很有可能是出現在sql上。
於是，我將程序中的sql複製出來，單獨在客戶端查詢，終於找到問題所在：查詢幾次反應時長基本在40s左右，最長的一次竟然用了61s。
於是便分析出原因，由於雲服務器存放的是所有醫院監控數據，日積月累數據量越來越大，所以導致查詢效率越來越低，解決的方案就是爲表對應的查詢條件所在列建立聯合索引，至此問題解決！