Go sql.DB WaitCount 为什么增长：用小实验看连接池预算怎么调

Go 的 database/sql 默认自带连接池。很多同学看到接口变慢时，会先怀疑 SQL 本身慢，但 DBStats.WaitCount 持续增长时，问题可能是：业务请求正在等可用数据库连接，而不是每条 SQL 都很慢。

这篇用一个后端实验室方式回答一个高频问题：WaitCount 为什么增长，SetMaxOpenConns 到底该怎么调？ 重点不是给一个万能数字，而是建立“连接预算 -> 观察指标 -> 调整 -> 复查”的闭环。

前置条件：先看懂 sql.DB 的连接预算

sql.DB 不是单条数据库连接，而是一个连接池句柄。它内部会按需创建、复用、回收连接。连接池里最常看的几个指标是：

• OpenConnections：当前打开的连接数。
• InUse：正在被查询占用的连接数。
• Idle：空闲可复用的连接数。
• WaitCount：因为连接池达到上限而等待的次数。
• WaitDuration：等待连接累计消耗的时间。

如果 MaxOpenConns=2，而高峰期有 20 个请求同时查库，那么多出来的请求必须排队。这个状态不是 SQL 语法错误，也不是 Go 协程卡住，而是连接预算不够。

初始化：准备一个可观察的连接池配置

先故意把连接池上限设小，方便观察等待现象。生产环境不要直接照抄这个数值，它只是实验参数。

package main

import (
    "context"
    "database/sql"
    "fmt"
    "log"
    "sync"
    "time"

    _ "github.com/go-sql-driver/mysql"
)

func openDB(dsn string) *sql.DB {
    db, err := sql.Open("mysql", dsn)
    if err != nil {
        log.Fatal(err)
    }

    db.SetMaxOpenConns(2)
    db.SetMaxIdleConns(2)
    db.SetConnMaxLifetime(30 * time.Minute)
    return db
}

这里最关键的是 SetMaxOpenConns(2)。它限制同一时刻最多打开 2 条数据库连接。只要并发查询超过这个预算，就会出现等待。

编写代码：并发查询和 DBStats 采样

下面用一组并发查询制造压力，同时每 200 毫秒打印一次连接池状态。查询语句可以换成你本地已有的小表，只要能稳定返回结果即可。

func printStats(ctx context.Context, db *sql.DB) {
    ticker := time.NewTicker(200 * time.Millisecond)
    defer ticker.Stop()

    for {
        select {
        case 

注意这里用 QueryContext，是为了让请求可以被超时或取消控制。真实接口里也建议从请求链路传入上下文，避免连接等待把接口拖得太久。

运行检查：WaitCount 增长说明什么

把采样和查询放在一起运行：

func main() {
    db := openDB("user:pass@tcp(127.0.0.1:3306)/app")
    defer db.Close()

    ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
    defer cancel()

    go printStats(ctx, db)
    runQueries(ctx, db, 80)
}

如果输出类似下面这样，就说明连接池上限已经成为队列入口：

open=2 in_use=2 idle=0 wait=18 wait_time=326ms
open=2 in_use=2 idle=0 wait=44 wait_time=912ms
open=2 in_use=1 idle=1 wait=57 wait_time=1.3s

读这组数据时按三步判断：

• in_use 长时间等于 MaxOpenConns：连接预算被打满。
• wait 持续增长：新请求拿不到连接，只能排队。
• wait_time 增长明显：排队已经影响接口耗时。

这时不能只把连接数一路调大。数据库本身也有连接上限，连接太多可能让数据库 CPU、内存、锁等待更糟。调参要结合数据库容量一起看。

扩展实验：调大连接池以后还要看哪些边界

把连接池上限调到一个更接近业务并发的数字，再重新跑同样的请求：

db.SetMaxOpenConns(8)
db.SetMaxIdleConns(4)
db.SetConnMaxLifetime(30 * time.Minute)

理想情况下，你会看到 WaitCount 增长变慢或停止，接口耗时下降，同时数据库仍然稳定。

调大以后还要看三类边界：

• 数据库连接上限：应用实例数乘以 MaxOpenConns，不要超过数据库可承受连接数。
• 慢查询比例：如果 SQL 本身慢，调大连接池只会让更多慢查询同时压到数据库。
• 空闲连接：Idle 长期过高说明预算可能偏大，浪费数据库资源。

清理总结：上线前的连接池检查清单

最后给一份更稳妥的检查清单，适合上线前或压测后使用：

• 先记录当前 OpenConnections、InUse、Idle、WaitCount、WaitDuration。
• 确认应用实例数量，计算总连接预算：实例数乘以 MaxOpenConns。
• 让 SetMaxIdleConns 小于或等于 SetMaxOpenConns，避免空闲连接过多。
• 给接口链路设置上下文超时，避免等待连接无限拖住请求。
• 结合慢查询日志一起看，区分“等连接”和“SQL 本身慢”。
• 调参后重新压测，确认 WaitCount、接口 P95、数据库 CPU 都在可接受范围。

总结一下：WaitCount 增长不是一个单独的错误码，而是连接池预算不足的信号。正确做法是先用 DBStats 证明是否在等连接，再按数据库容量和接口并发调整 SetMaxOpenConns，最后用同一组指标复查效果。