Golang mysql 上線的一個坑 Db.close重要性

急衝衝完成的mysql的一個監控自動處理程序上線了，線下處理是正常的，沒想到線上才半小時就奔潰了。

如今時間是晚上11點，心慌焦慮涌上心頭，須要熬夜？腎上腺素激增。

程序主要是一個定時任務的處理程序，主要是對mysql 的處理，初看沒啥問題，操做語句都是網上搬下來的，檢查了下代碼，

奔潰都在什麼rows.close，stmt.close，還有query這時候，非法defer，這個奔潰的最屢次，還都是內存指針異常。。。 golang這調試，說實在連c++都不如，在可能我還用不慣吧，我用的是liteide

隨便截取段代碼：

rows, err := db.Query("select * from user;")
    if err != nil {
        log.Fatal(err)
    }
    defer rows.Close()

基本上網上大部分都是這種狀況，rows.close，stmt.close 等都有，可是惟獨沒有db.close。爲何？ 他們說有

Db.SetMaxOpenConns(200)
Db.SetMaxIdleConns(100)
Db.Ping()

　　線程池。全部代碼中都說不須要close，可是那是有條件的。

咱們查看官方的解釋

// It is rare to Close a DB, as the DB handle is meant to be

// long-lived and shared between many goroutines.

但在實際使用中，都說了是定時任務天然是go func的，而後使用一個公共的Db，還有一個注意的問題，雖然鏈接放進鏈接池，可是服務器依然會單方面斷開一個的鏈接。

關鍵是並且使用Db.Ping()依然不能解決這個問題，緣由沒細查。

如今知道了緣由，解決起來就容易多了，結尾必定加

Db.Close()

什麼rows.close，stmt.close反而不重要，後面測試發現無關緊要，凌晨1點了，收工。