MySQL中MaxIdleConns變成短連接的原因是什么

這期內容當中小編將會給大家帶來有關MySQL中MaxIdleConns變成短連接的原因是什么，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

 配置解讀

maxIdleCount      int                    // zero means defaultMaxIdleConns; negative means 0
maxOpen      int          // <= 0 means unlimited
maxLifetime    time.Duration     // maximum amount of time a connection may be reused
maxIdleTime       time.Duration          // maximum amount of time a connection may be idle before being closed

可以看到以上四個配置，是我們Go MySQL客戶端最重要的配置。

maxIdleCount 最大空閑連接數，默認不配置，是2個最大空閑連接

maxOpen 最大連接數，默認不配置，是不限制最大連接數

maxLifetime 連接最大存活時間

maxIdleTime 空閑連接最大存活時間

 源碼解析

我們的場景是客戶端與MySQL建立的連接數經常大于最大空閑連接數，這會導致什么問題？我們看下下圖中的源碼。

我們可以看到，當最大空閑連接數小于客戶端與數據庫建立的連接數的時候，那么就會返回false，并且最大連接數關閉計數器加1。

然后上圖中，我們就可以看到，連接被關閉了（MySQL源碼里也不留點緩沖時間再關閉）。Go的MySQL客戶端這個操作，就會導致當突發流量情況下，由于請求量級過大，超過了最大空閑連接數的負載，那么新的連接在放入連接池的時候，會被無情的關閉，變成短連接，導致你的服務性能進一步惡化。

實驗

模擬線上并發數大于MaxIdConns情況

測試代碼 , 為了檢測以上邏輯，假設了以下場景，設置最大連接數為100，最大空閑連接數為1，并發數為10的goroutine來請求數據庫。我們通過MySQL的stats的maxIdleClosed的統計，可以看到下圖，我們的連接不停的被關閉。

模擬線上并發數小于MaxIdConns情況

測試代碼 ，假設了以下場景，設置最大連接數為100，最大空閑連接數為20，并發數為10的goroutine來請求數據庫，可以看到下圖中，無MaxIdleClosed的關閉統計。

抓包驗證線上并發數大于MaxIdConns情況

測試代碼 ，為了驗證沒有理解錯代碼，抓個包最穩妥。我們將main函數里放個select{}，程序執行完mysql的語句后，看下tcp狀態和抓包數據。

可以發現確實是tcp的狀態統計與MySQL客戶端的統計是一致的，并且存在fin包。

上述就是小編為大家分享的MySQL中MaxIdleConns變成短連接的原因是什么了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。