Go sql.DB.SetMaxOpenConns 设为一后为什么吞吐变低

线上把 db.SetMaxOpenConns(1) 加进去后，查询结果没有变，吞吐却明显下降，最常见的原因不是数据库突然变慢，而是所有并发请求都在争用同一条连接。sql.DB 会把暂时拿不到连接的操作挂起等待；当查询平均耗时为 20 毫秒时，理论上这条单连接通道每秒最多只能完成约 50 次串行查询，还没算事务、网络和排队开销。

为什么设为一会把并发压成单车道

官方文档把 SetMaxOpenConns(n) 定义为数据库打开连接数上限，n 才是不限制。它不是“每个请求一条连接”，而是整个 *sql.DB 共享一个上限。多个 goroutine 同时执行 QueryContext、ExecContext 或开启事务时，只有一个能占用连接，其余操作要等前一个归还。

因此，单连接适合验证串行访问、保护极小数据库实例，或某些明确要求单会话的场景；它不适合把普通 Web 请求池直接当成生产默认值。即使数据库 CPU 还有余量，应用侧也可能已经在连接池门口排队。

先用 DBStats 判断到底慢在哪里

不要只看接口平均耗时。把配置变更前后的 DBStats 采样放在同一压测窗口，重点看等待计数与等待时长：

func logPoolStats(db *sql.DB, logger *log.Logger) {
	stats := db.Stats()
	// 记录累计值；监控系统应使用相邻采样的增量。
	logger.Printf("open_limit=%d open=%d in_use=%d idle=%d wait_count=%d wait_duration=%s",
		stats.MaxOpenConnections, stats.OpenConnections, stats.InUse,
		stats.Idle, stats.WaitCount, stats.WaitDuration)
}

例如把上限从 10 改为 1 后，WaitDuration 增长而数据库慢查询没有同步增加，结论就很明确：瓶颈在连接获取阶段。注意这些字段是累计统计，应该比较一分钟内的增量，不能拿启动以来的总数直接和一次请求对比。

按真实连接预算重新设定上限

调大并不等于无限调大。先算所有应用实例、后台任务和只读副本可能同时占用的连接，再扣掉数据库为管理、复制和其他服务保留的余量。如果前面还有连接代理，还要以代理的后端连接限制为硬上限。读写混在一个池里时，一个慢事务也会占住名额，必要时可拆成读池、写池或给长事务单独治理。

连接池参数可以先这样落地，再用压测修正：

db.SetMaxOpenConns(20)
db.SetMaxIdleConns(10)
db.SetConnMaxLifetime(30 * time.Minute)

// 请求级超时要覆盖排队和执行，避免连接池无限积压。
ctx, cancel := context.WithTimeout(req.Context(), 800*time.Millisecond)
defer cancel()
err := db.QueryRowContext(ctx, "SELECT status FROM jobs WHERE id = ?", jobID).Scan(&status)

MaxIdleConns 只是空闲连接保留数，不是并发上限；当它大于新的 MaxOpenConns 时会被同步压低。修改参数后同时观察 P95/P99、超时数、数据库 CPU、锁等待和连接错误，找到“等待明显下降但数据库仍有余量”的点，再做小流量发布。

常见问题

SetMaxOpenConns(1) 一定是错误配置吗？

不一定。单连接可以作为串行化手段或低资源实例的保护阀，但要接受并发吞吐受查询耗时限制，并确认所有调用共享的是同一个池。

WaitCount 很大是不是说明数据库连接泄漏？

不是。它只说明曾经有操作等待连接。是否泄漏要结合 InUse 长期不回落、连接未关闭、事务未提交以及驱动行为一起排查。

只把上限从 1 改成 100 就能解决吗？

不能。过大的池会把压力转移给数据库和代理，还可能放大锁竞争。应按实例数、数据库预算和压测曲线逐步调节。

参考：database/sql SetMaxOpenConns、database/sql DB.Stats。