绝大多数情况下是SQL问题，需先用慢查询日志、EXPLAIN和SHOW PROCESSLIST定位；若EXPLAIN显示type=ALL或rows远超实际行数，则确认为SQL未走索引等问题。
查询慢是SQL问题还是Go代码问题？先定位
绝大多数情况下，Golang应用查数据库慢，根源不在database/sql包本身，而在于SQL语句没走索引、连接池配置不当或事务没及时释放。别急着改Go代码，先用数据库原生工具确认瓶颈：开慢查询日志（MySQL的slow_query_log）、用EXPLAIN看执行计划、检查SHOW PROCESSLIST里有没有长期阻塞的连接。如果EXPLAIN显示type=ALL或rows值远大于表实际行数，基本可以确定是SQL问题；如果连接数频繁打满、PING延迟高，再查Go侧连接池。
连接池参数SetMaxOpenConns和SetMaxIdleConns怎么设才合理
这两个参数不是越大越好，设错反而加剧锁竞争或内存泄漏。关键看你的QPS和单次查询耗时：
-
SetMaxOpenConns：建议设为「峰值QPS × 平均查询耗时（秒）」向上取整，比如峰值100 QPS、平均查一次200ms，就设db.SetMaxOpenConns(20)（100 × 0.2 = 20）；超过这个值，db.Query会阻塞等待空闲连接 -
SetMaxIdleConns：通常设为SetMaxOpenConns的1/2～2/3，避免空闲连接过多占用DB资源；但不能小于1，否则每次查询都要新建连接 - 必须调用
db.SetConnMaxLifetime（如30 * time.Minute），防止DB端主动断连后Go还拿着失效连接重试失败
db, _ := sql.Open("mysql", "user:pass@tcp(127.0.0.1:3306)/test")
db.SetMaxOpenConns(20)
db.SetMaxIdleConns(10)
db.SetConnMaxLifetime(30 * time.Minute)
用QueryRow还是Query？批量查询怎么避免N+1
选错API会导致隐式全表扫描或多次往返：
- 只查一行且必有结果，用
QueryRow；可能无结果或要遍历多行，必须用Query+rows.Next()循环，否则QueryRow.Scan遇到空结果会报sql.ErrNoRows，而Query不会 - N+1问题常见于for循环里反复调
db.QueryRow查关联数据，应改用IN一次性查出所有ID对应的数据，或用JOIN在SQL层合并 - 大批量写入别用
Exec一条条插，改用INSERT INTO ... VALUES (...), (...), (...)拼成批量语句，或开启Prepare复用stmt
事务里没tx.Commit()或tx.Rollback()会卡死连接池
这是最隐蔽也最常踩的坑：事务开始后，无论成功失败，都必须显式调用Commit()或Rollback()。漏掉任何一个，该连接会一直被占用，直到ConnMaxLifetime超时或DB主动踢掉，期间所有新请求都在db.Query处阻塞。
立即学习“go语言免费学习笔记（深入）”；
正确写法必须带defer兜底：
tx, err := db.Begin()
if err != nil {
return err
}
defer func() {
if p := recover(); p != nil {
tx.Rollback()
panic(p)
}
}()
_, err = tx.Exec("INSERT INTO users(name) VALUES(?)", name)
if err != nil {
tx.Rollback()
return err
}
return tx.Commit()
更稳妥的做法是用sql.Tx封装函数，确保Commit或Rollback至少执行一个。连接池卡死往往不是性能问题，而是逻辑遗漏。