caojia/go-orm

go-orm's Issues

非常偶然的情况下，日志不能正常记录explain的输出

非常偶然的情况下，我看到日志只输出explain的3个字段，并且前面有一条错误日志，具体如下：
2018-09-29 09:46:15.397286 I | reflect err sql: Scan error on column index 6: converting driver.Value type []uint8 ("8,98") to a int64: invalid syntax
2018/09/29 09:46:15 [3] - - [SQL] [slow] duration: 34.608907ms, sql: select c.* from core_info as c where c.is_deleted = 0 and c.api_uuid='license' and c.person_check_id='3832568' and c.data_requested_at > '2017-09-29 09:46:15 +0800 CST' order by c.core_info_id desc limit 1[], explain: [{"table":"c","type":"index_merge","key":"idx_person_check_id,idx_api_uuid"}]

正常的日志的explain应该有7个字段，具体如下：
018/09/29 12:44:44 [2] - - 开始获取本地数据
2018/09/29 12:44:44 [3] - - [SQL] [slow] duration: 13.821561ms, sql: select c.* from core_info as c where c.is_deleted = 0 and c.api_uuid='license' and c.person_check_id='4358419' and c.data_requested_at > '2017-09-29 12:44:44 +0800 CST' order by c.core_info_id desc limit 1[], explain: [{"table":"c","type":"ref","key":"idx_person_check_id","key_len":8,"ref":"const","rows":8,"extra":"Using where"}]

我分析这些日志是在解析explain的时候打出来的，但是不能测试环境中复现出现象

我使用的环境：
go版本：go1.10.3
go-orm id：8f43191b5d0221c2d728c7fad0da61227254e6a5

并发数超过连接池最大连接数在获取连接阻塞bug

func query(c context.Context, tdx Tdx, queryStr string, args ...interface{}) (res *sql.Rows, err error) {
queryStr = addLimit(queryStr, 0)
queryStr, args = changeSQLIn(queryStr, args...)
start := time.Now()
if res, err = tdx.Query(queryStr, args...); err != nil {
return res, err
}
duration := time.Since(start)

var exp []*Explain
if sqlLogger.ShowExplain(duration) {
	go func() {
		exp, err := doExplain(tdx, queryStr, args...)
		if err != nil {
			return
		}
		logPrint(c, sqlLogger, exp, duration, queryStr, args...)
	}()

}
logPrint(c, sqlLogger, exp, duration, queryStr, args...)
return res, nil

}

query里执行doExplain 这个函数doExplain 应该异步执行或者去掉doExplain逻辑，否则并发query 并发数超过数据库连接池的最大连接数并sqlLogger.ShowExplain(duration) 为ture就很有可能会阻塞死。
为什么会这样呢？
tdx.Query ### 获取一个连接还没有释放，你就doExplain又去获取连接。相当于申请一个连接1，再申请连接2，释放连接2，再释放连接1.如果申请连接2的时候连接池已经满了，连接2 申请阻塞，导致连接1释放不了，连接池这种错误用法很典型。