MySQL的MaxIdleConns不合理，會變成短連接的原因

Posted on by

1 背景

最近石墨文檔線上業務出現瞭一些性能問題，在突發流量情況下，有個業務性能急劇下降。該服務是依賴於數據庫的業務，會批量獲取數據庫裡的數據。在經過一系列的排查過程後，發現該服務到數據庫的連接數經常超過MaxIdleConns，因此懷疑是數據庫的配置導致的性能問題，所以以下針對數據庫的代碼進行瞭剖析，並做瞭相關實驗。

2 配置解讀

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 空閑連接最大存活時間

3 源碼解析

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

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

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

4 實驗

4.1 模擬線上並發數大於MaxIdConns情況

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

4.2 模擬線上並發數小於MaxIdConns情況

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

4.3 抓包驗證線上並發數大於MaxIdConns情況

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

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

5 總結

當突發流量情況下，由於請求量級過大，超過瞭最大空閑連接數的負載，那麼新的連接在放入連接池的時候，會被關閉，將連接變成短連接，導致服務性能進一步惡化。為瞭避免這種情況，下面列舉瞭，可以優化的措施。

提前將maxIdleConns設大，避免出現短連接

做好mysql讀寫分離

提升mysql的吞吐量：精簡返回字段，沒必要的字段不要返回，能夠夠快復用連接

吞吐量的包盡量不要太大，避免分包

優化連接池，當客戶端到MySQL的連接數大於最大空閑連接的時候，關閉能夠做一下延遲（官方不支持，估計隻能自己實現）

讀請求的最好不要放MySQL裡，盡量放redis裡

6 測試代碼

https://github.com/gotomicro/test/tree/main/gorm

以上就是MySQL的MaxIdleConns不合理，會變成短連接的原因的詳細內容，更多關於MySQL的MaxIdleConns不合理的資料請關註WalkonNet其它相關文章！

推薦閱讀：