Go标准库自带的database/sql加上go-sql-driver/mysql驱动，是绝大多数Go后端操作数据库的组合。这套组合上手简单，但如果只是照着文档写Query就上线，遇到高并发或复杂业务时，接口耗时往往会在数据库这一层明显放大。特别是同一个请求里要执行十几次甚至上百次SQL的场景，不优化的代码和优化后的代码，性能差距可能达到一个数量级。本文从连接复用、语句预编译、查询模式改造三个层面，讲清楚多次查询的优化思路。
一、先搞清楚连接池：多次查询性能的第一道关卡
很多Go新手写代码时习惯在每个函数里都调用sql.Open，以为这样更隔离。实际上sql.Open并不会真正建立连接，它只是初始化一个连接池对象，真正的连接是在首次执行SQL时惰性创建的。如果你在业务代码里反复Open再Close，等于每次查询都要经历TCP三次握手、MySQL认证、TLS协商这一整套流程，单次开销可能就要几毫秒到几十毫秒，多次查询叠加下来开销非常可观。
正确做法是全局只维护一个*sql.DB实例，并手动调整连接池参数。默认配置下MaxOpenConns和MaxIdleConns在老版本驱动里都很保守，并发一上来就会频繁建连断连。下面是一份比较实用的配置：
var db *sql.DB
func initDB() error {
dsn := "user:password@tcp(127.0.0.1:3306)/mydb?charset=utf8mb4&parseTime=true"
var err error
db, err = sql.Open("mysql", dsn)
if err != nil {
return err
}
// 最大打开连接数，根据MySQL的max_connections和业务并发评估
db.SetMaxOpenConns(100)
// 最大空闲连接数，建议与MaxOpenConns接近，避免频繁关闭重建
db.SetMaxIdleConns(100)
// 空闲连接最长存活时间，超过后自动回收，防止拿到已被服务端断开的连接
db.SetConnMaxLifetime(5 * time.Minute)
return db.Ping()
}这里有个容易踩的坑：MaxIdleConns如果远小于MaxOpenConns，高峰期新建的连接在低谷期会被立即关闭，下一个高峰又要重新建连，形成连接震荡。另外SetConnMaxLifetime设置成5分钟左右比较稳妥，因为有些MySQL服务端或中间件会主动kill长时间空闲的连接，客户端如果不感知，就会拿到坏连接报错。
二、预编译与参数化查询：别让SQL解析拖慢循环
当你在一个循环里执行结构相同、参数不同的SQL时，每次Query都会让MySQL重新解析SQL文本、生成执行计划。Go的database/sql其实内置了语句缓存，当你使用占位符时，驱动会自动Prepare并复用预编译语句，但前提是你写法正确。对比下面两种写法：
// 反例：拼接SQL，既无法复用执行计划，还有注入风险
for _, id := range ids {
query := fmt.Sprintf("SELECT name, price FROM products WHERE id = %d", id)
rows, err := db.Query(query)
// ...
}
// 正例：使用占位符，驱动自动缓存预编译语句
for _, id := range ids {
rows, err := db.Query("SELECT name, price FROM products WHERE id = ?", id)
// ...
}如果循环次数特别多，还可以显式使用db.Prepare拿到*sql.Stmt，手动控制预编译语句的生命周期，在循环结束后调用stmt.Close归还资源。需要注意Stmt绑定在连接池上，并发使用时内部会做连接绑定处理，性能略低于直接Query但可控性更强。另一个细节是go-sql-driver/mysql支持在DSN里加上interpolateParams=true参数，开启后驱动会在客户端把参数直接填进SQL文本，省去一次往返，适合简单参数类型的场景。
参数化查询还有个隐藏收益：相同的SQL文本会被MySQL的查询缓存机制友好对待（尽管MySQL 8.0已移除Query Cache，但执行计划层面的复用依然存在），而且从根本上杜绝了SQL注入问题，属于一举两得的改法。
三、干掉N加1查询：用一次批量查询替代N次单查
多次查询最大的性能杀手不是单条SQL慢，而是查询次数多。典型场景是先查订单列表，再循环查每个订单的用户信息，10条订单就是11次SQL，100条订单就是101次。每次网络往返按1毫秒算，纯网络开销就超过100毫秒。解决思路是把循环查询改造成IN批量查询：
// 反例：N加1查询
orders, _ := queryOrders(limit)
for i := range orders {
user, _ := queryUserByID(orders[i].UserID)
orders[i].UserName = user.Name
}
// 正例：先收集ID，一次IN查询，再在内存里组装
userIDs := make([]int64, 0, len(orders))
for _, o := range orders {
userIDs = append(userIDs, o.UserID)
}
// 动态生成占位符
placeholders := strings.Repeat("?,", len(userIDs))
placeholders = strings.TrimSuffix(placeholders, ",")
args := make([]interface{}, 0, len(userIDs))
for _, id := range userIDs {
args = append(args, id)
}
rows, err := db.Query("SELECT id, name FROM users WHERE id IN ("+placeholders+")", args...)改造后无论多少条订单，用户信息永远只需要一次SQL。在内存里用map把结果按ID索引，再回填到订单上，整体耗时会从线性增长变成近似常数。需要注意IN列表也不宜过长，一般控制在1000个以内，超过就分批查询。另外记得给IN查询的字段建索引，否则批量查询本身也会退化成全表扫描。
四、索引、慢日志与缓存：多层兜底策略
连接和查询模式都优化完之后，如果单条SQL依然慢，就要回到数据库本身排查。先用EXPLAIN看执行计划，重点关注type列是否出现ALL（全表扫描）、key列是否为空。复合索引的设计要遵循最左前缀原则，比如经常按user_id加status加create_time过滤，就建(user_id, status, create_time)的联合索引，让过滤条件尽量走索引。
其次开启慢查询日志，把long_query_time设置成0.1秒甚至更低，在测试环境压测一轮，把真实慢SQL抓出来针对性优化。Go侧也可以在代码里对每次查询做埋点，封装一个带耗时的查询函数，超过阈值就打日志告警：
func queryWithMetric(ctx context.Context, query string, args ...interface{}) (*sql.Rows, error) {
start := time.Now()
rows, err := db.QueryContext(ctx, query, args...)
cost := time.Since(start)
if cost > 100*time.Millisecond {
log.Printf("[slow sql] cost=%s query=%s", cost, query)
}
return rows, err
}最后对于读多写少的数据，比如配置项、商品分类这类几乎不变的内容，在Go进程内加一层本地缓存，用sync.Map或带过期的cache库挡住大部分请求，或者在架构层面引入Redis做分布式缓存，能让MySQL的查询量下降一个数量级。缓存要注意失效策略和击穿防护，常用做法是singleflight合并并发请求，确保缓存过期瞬间只有一个协程去查库。
总结一下优化路径：先保证连接池配置合理，再消灭循环里的重复查询和N加1问题，然后借助索引和慢日志打磨单条SQL，最后用缓存承接热点读。多数业务系统按这个顺序做完，接口耗时应能从几百毫秒降到个位数毫秒级别。
Go MySQL优化数据库连接池SQL查询性能修改时间：2026-09-15 22:26:48