點擊上方“IT實戰聯盟”，關註“頭條號”領導要高高在上平時多聽聽他人的意見然後認真記下來到底是誰對你有意見背景很少用的一個業務後臺管理端需要導入一批數據（200多條），用戶在導入的時候沒有成功。業務場景比較復雜，需要將每條數據去數據庫匹配、關聯、分析後再將結果進行更新。大約涉及5張表、3000多萬筆數據。報錯日志分析從報錯日志上來看，主要是由於連接時間過長，導致連接失效。那麼那失效的連接去請求數據庫就會報上圖的異常。排查步驟第一步：檢查數據庫連接池設置的超時時間首先想到的是項目中配置的數據庫連接池超時時間設置小瞭，具體配置如下：spring.datasource.max-wait: 120000那就“豪放”一點加個 0 ，測試發現依然報錯。第二步：分析報錯數據連接池的超時時間沒有問題那就分析一下具體的報錯數據，是否由於數據原因導致。修改日志級別（由於該功能一直在正常使用，日志級別是debug），將報錯數據進行輸出。排除因導入文件格式、內容編碼格式等因素。根據打印的數據拼接SQL到數據庫進行執行也是正常的，接著連續重試多次上傳功能每次引起報錯的數據也不是同一個。第三步：分析業務SQL首先反應的是代碼塊有慢SQL導致連接超時，根據日志報錯的代碼行將SQL單獨執行是毫秒級的，並且隻有一個用戶操作是單線程，這樣也不存在並發現象。排除慢SQL 問題。第四步：分析底層報錯日志項目業務和SQL層面排查完畢後，沒有定位到問題根本原因，隻能繼續分析報錯日志。從上圖看到和查詢結果集的數據類型有關，難道匹配的數據存在null、或者類型有問題？再一次執行瞭報錯數據，認真的檢查瞭一遍數據類型和數據信息都正常，沒有特別的地方。到這裡卡殼瞭……第五步：求助 MySQl Bug 網站其實已經定位到是mysql 的問題，但是具體原因和解決方案還沒有找到，這裡隻能到MySQL Bug 官網去碰一碰運氣。https://bugs.mysql.com/bug.php?id=41484找到瞭和我們一樣的問題記錄，大致是 mysql 連接池的某個版本的Bug，這裡趕緊看一下自己項目中用的是哪個版本：compile('mysql:mysql-connector-java:5.1.39')雖然從版本來看是比較低，但是找瞭一圈也沒有看到從哪個版本起修復瞭這個問題，難道要升級到最新的8.x ？但是項目是比較老的，升級後需要經過完整的回歸測試才行，並且短時間內沒辦法進行全面的測試。第六步：臨時升級 mysql-connector-java經團隊討論可以進行臨時的升級解決用戶的問題，然後再降級優化業務邏輯解決問題，甚至後續可以進行重構。升級為 6.x……執行……問題依然存在！！！第七步：求助 DBA半夜打 DBA 電話幫忙看一下數據庫層面是否可以給一些建議，DBA 查詢數據庫設置超時時間：show global variables like '%timeout%';等待時間隻有 180 秒，其他數據庫的超時時間都是 28800（默認8小時）。修改數據庫超時時間為28800，再次執行成功。總結最近數據庫做過遷移，DBA 回復這個超時時間應該都是統一默認的，不知道在什麼時候被修改瞭。雖然通過修改數據庫設置的方式解決瞭問題，但是在業務設計層面也存在問題。整個上傳服務前同事用的是一個大事務，要麼全部成功，要麼全部失敗。在業務量小的時候是不會遇到這個問題的，但是隨著需求的不斷迭代，系統的復雜度越來越高就暴露出來瞭。無意中發現瞭 mysql 連接的一個bug，雖然比較老但是也有收獲。歡迎大傢關註“IT實戰聯盟”頭條號，後續有更多的踩坑問題分享給大傢……
本文出自快速备案，转载时请注明出处及相应链接。
