Go database/sql 怎样设置连接池上限

我第一次给 Go 服务调数据库连接池时，直觉是把连接数调大，结果应用并没有更快，数据库反而更容易触顶。后来我把问题拆成两件事：先算这一个服务最多能拿多少连接，再让 database/sql 按这个预算复用连接。

结论是：在应用启动阶段复用一个全局 *sql.DB，用 SetMaxOpenConns 设定打开连接总上限，用不超过它的 SetMaxIdleConns 控制空闲连接，并根据数据库或代理的存活时间设置轮换参数。官方资料：https://go.dev/doc/database/manage-connections

先从数据库额度里划出应用预算

MaxOpenConns 不是“每个请求一个连接”的开关，而是这个 sql.DB 允许同时打开的连接总数。比如数据库为某个实例预留 80 个连接，应用还要给迁移任务、管理工具和其他服务留出余量，那么 Go 服务不应该直接拿满 80 个。

我通常先写成一个能解释的预算：数据库分给应用的额度减去固定余量，再除以同一实例上的 Go 服务数量。得到的数还要结合 SQL 持有连接的时间、请求并发和数据库 CPU 一起观察，不能只按机器核数拍脑袋。

在启动阶段设置三类连接池参数

下面的初始化函数只做连接池配置和连通性检查。重点是 sql.Open 返回池句柄，服务生命周期内应该复用它，不要在每个请求里重复打开数据库。

package main

import (
    "context"
    "database/sql"
    "fmt"
    "time"
)

func openDB(dsn string) (*sql.DB, error) {
    // Open 创建可并发复用的连接池句柄，不等于已经建立了一条连接。
    db, err := sql.Open("mysql", dsn)
    if err != nil {
        return nil, err
    }

    // 这里的 24 只是示例，应替换为按数据库额度算出的服务预算。
    db.SetMaxOpenConns(24)
    // 空闲连接通常小于打开上限，避免低流量时长期占用额度。
    db.SetMaxIdleConns(6)
    // 轮换时间要短于数据库、代理或负载均衡器的连接存活限制。
    db.SetConnMaxLifetime(30 * time.Minute)
    db.SetConnMaxIdleTime(5 * time.Minute)

    ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
    defer cancel() // 只释放本次 Ping 的上下文资源，不关闭全局连接池。
    if err := db.PingContext(ctx); err != nil {
        db.Close() // 初始化失败时关闭池，避免留下未使用的资源。
        return nil, fmt.Errorf("ping database: %w", err)
    }
    return db, nil
}

三个参数要分开理解：MaxOpenConns 控制并发连接总量；MaxIdleConns 影响突发流量后的复用能力；SetConnMaxLifetime 和 SetConnMaxIdleTime 负责连接轮换。空闲上限可以不超过打开上限，连接生命周期也不要短到让每个请求都频繁重连。

用 DBStats 判断上限是过小还是过大

参数设置后不要只看数据库端的连接数。db.Stats() 可以告诉我们当前打开、使用中和空闲的连接数量。采样时关注组合关系：OpenConnections 长时间贴近上限且 InUse 很高，说明池可能需要排队；Idle 长时间偏高而流量很低，说明空闲上限或回收时间可能偏大。

type PoolView struct {
    Open  int
    InUse int
    Idle  int
}

func poolView(db *sql.DB) PoolView {
    // Stats 是当前池的快照；它不替代数据库端的容量监控。
    s := db.Stats()
    return PoolView{
        Open:  s.OpenConnections,
        InUse: s.InUse,
        Idle:  s.Idle,
    }
}

如果 InUse 长时间不下降，先查 Rows.Close、事务提交或回滚、请求上下文取消等归还路径，不要马上把上限继续调大。连接池上限过小会增加等待，过大则可能把并发压力集中推向数据库；一次只改一个参数，才能知道变化来自哪里。

上线前检查连接是否真的能归还

调大 MaxOpenConns 前，先检查所有查询返回的 Rows 是否关闭，事务是否在成功和失败路径分别提交或回滚，慢 SQL 是否绑定了带截止时间的上下文。连接没有归还时，任何更大的上限都只是把问题推迟。

常见问题

MaxOpenConns 应该设置成 CPU 核数吗？ 不应该直接这样推导。它首先受数据库连接额度、SQL 持有时间和同实例服务数量约束，CPU 只是需要观察的因素之一。

MaxIdleConns 越大越好吗？ 不是。空闲连接能减少突发重连，但也会长期占用数据库和代理资源，应让它匹配平时并发，而不是盲目接近打开上限。

设置上限后请求变慢怎么办？ 先用 DBStats 和请求耗时确认是排队、连接泄漏还是 SQL 本身变慢，再决定调参；不要只看到等待就把数据库连接额度全部用满。