Golang mysql 上线的一个坑 Db.close重要性

2022-07-31 20:30:00

急冲冲完成的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点了，收工。

今早上起来，一切OK，运行了1个晚上

码农公寓