最近在使用go语言操作数据库的时候遇到个隐藏的问题，这种问题很难定位，最后经过多方测试、尝试、猜测最后才确认问题，问题是这样的：

        当时我们当时用的go的gin框架做后台服务、使用mysql作为后台数据库，然后在初始化的时候设置了go数据库操作线程池，这个线程池是go语言自带的线程池，我们只需要设置一些参数就可以实现数据库线程池。然后最后测试测出来不知道什么原因，经过一段时间的测试，服务卡死了，所有的访问都无法正常访问；最开始是找路由框架的问题，找了半天也没找到问题，后面又猜测是非法字符操作的问题，最后经过各种测试发现是功能函数里面有个系统函数没用对，导致线程池到达上限，所有访问卡死。具体的导致原因和解决方法如下所示：

        我们在线程池设置的地方是这样设置的：

const (dbMaxLiftTime  = 2 * time.HourdbMaxIdleConns = 30dbMaxOpenConns = 100
)G_dbpap, err := sql.Open("mysql", mysqlurl)
if err != nil {golog.Error(err)return err
}
G_dbpap.SetMaxIdleConns(dbMaxIdleConns)   //连接池的空闲数大小
G_dbpap.SetMaxOpenConns(dbMaxOpenConns)   //设置最大打开连接数
G_dbpap.SetConnMaxLifetime(dbMaxLiftTime) //设置连接的最大生存时间

上面的代码中，我们打开了一个G_dbpap的全局操作mysql数据库的变量，然后我们设置了线程池，最大打开访问连接数为100，这个设置是导致我出现问题的关键，另外两个根据字面上的意思也能理解，记住这个100

然后我代码中有个API接口函数是这样写的：

sql_cmd := `DELETE FROM TABLEDATA`
_,err := G_dbpap.Query(sql_cmd)
if err != nil{return err
}

注意这个G_dbpap.Query，我看了他函数源码里面他的第一个返回值是Rows指针，下面附上了源代码

func (db *DB) Query(query string, args ...any) (*Rows, error) {return db.QueryContext(context.Background(), query, args...)
}

我之前也看了很多资料知道这个rows返回值用完必须要手动close，但是就是因为这个地方我图方便，因为是删除语句，我不需要处理返回值就用了下划线略过返回值，其实是有问题的，这个rows不close的话，这一次的请求线程就会一直占用，不会释放，所以接口测试超过100次，这个线程占用就会达到100次，然后上面设置的线程池最大连接数就是100次，所以就导致100次的接口测试后，所有使用G_dbpap句柄操作数据库的访问请求都会卡死。因为设置了最大线程池大小，达到最大后，访问请求就会等到之前的线程释放掉才会响应。

当时的心情真的很激动，折磨好久的问题终于定位到原因，然后怎么解决呢，两种方法：

1、像上面那种数据库操作请求，因为不需要返回值，所有只需将Query换成Exec执行数据库即可，如下所示

sql_cmd := `DELETE FROM TABLEDATA`
_,err := G_dbpap.Exec(sql_cmd)
if err != nil{return err
}

2、如果不像上面的那种，需要处理返回值的数据库操作，如select的，需要再使用完rows后close掉，如下所示

sql_cmd := `SELECT * FROM TABLEDATA`
rows,err := G_dbpap.Query(sql_cmd)
if err != nil{return err
}for rows.Next() {//获取rows的返回值操作}rows.Close()

这样用完操作然后Close掉才不会出现问题。

备注：从上面的情况来看，其实出现原因也是我自己的问题，删除操作数据库的操作函数不该用Query函数，但是其实我也非常感谢我用错，不用错，我就不会深刻理解用了Query没有Close会导致什么严重的后果。还有就是有人或许会说，如果数据库线程池操作那个不设置那100的限制，应该也不会出现这个问题，其实大家再仔细想想，如果前面没有设置那100的限制（好像默认是无上限），那么最后出现问题可能是灾难性的，设想没有释放的线程越来越多，最后导致系统崩了，到那时可能定位问题更是艰难无比了。

以上就是我此次遇到的问题和解决方法，记录于此，希望对后面的朋友有所帮助。