MySQL 连接池配置连接池避免拿到失效连接的实现方法

MySQL 连接池出现“偶发第一次查询失败”，通常不是把连接数调大就能解决。更稳妥的做法是让客户端连接生命周期短于服务端的空闲回收时间，配合启动探活、请求超时和只针对幂等操作的有限重试。MySQL 官方手册中的 wait_timeout 控制非交互连接空闲多久后关闭，单位是秒。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/server-system-variables.html

核心配置关系可以记成：连接池的 ConnMaxLifetime 要留出安全余量，不能晚于 MySQL 的 wait_timeout；重试只覆盖已经确认没有提交副作用的查询。

• 先查服务端的 wait_timeout，再决定客户端生命周期。
• 同时设置最大打开数、最大空闲数和空闲连接寿命。
• 将失效连接修复与业务重试分开，事务写入不要盲目重放。

先对齐 wait_timeout 与连接生命周期

连接池保存的是可复用的会话，不等于连接永远有效。MySQL 8.4 文档说明，wait_timeout 是非交互连接无活动时，服务器等待并关闭连接的秒数；它既有全局值，也会在会话创建时形成会话值。先在目标实例执行下面的查询，确认当前配置，不要直接套用默认值：

-- 只读取当前实例的连接空闲回收参数
SHOW GLOBAL VARIABLES
WHERE Variable_name IN ('wait_timeout', 'interactive_timeout');

如果 wait_timeout 是 1800 秒，客户端就不应把连接生命周期设成 1800 秒。可先预留 5%～10% 的时间差，例如用 1600～1700 秒作为起点，再结合网络设备的空闲连接策略调整。ConnMaxLifetime 是连接从创建到被池淘汰的上限，不是一次 SQL 的执行超时；后者应由请求上下文控制。

用 database/sql 配置连接池边界

Go 的 database/sql 通过 sql.DB 管理连接池。下面的配置把“总量”“空闲量”“寿命”分开处理；数值只是示例，应按实例最大连接数、应用副本数和查询耗时压测：

package dbpool

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

func Open(ctx context.Context, driver, dsn string) (*sql.DB, error) {
    // Open 主要初始化池；Ping 才负责确认当前实例可达。
    db, err := sql.Open(driver, dsn)
    if err != nil {
        return nil, fmt.Errorf("open mysql pool: %w", err)
    }

    // 让客户端在 wait_timeout 之前回收连接，避免把旧连接长期留在池中。
    db.SetConnMaxLifetime(25 * time.Minute)
    db.SetConnMaxIdleTime(5 * time.Minute)
    db.SetMaxOpenConns(30)
    db.SetMaxIdleConns(10)

    // 启动探活使用独立超时，失败时关闭已创建的池，避免资源泄漏。
    pingCtx, cancel := context.WithTimeout(ctx, 2*time.Second)
    defer cancel()
    if err := db.PingContext(pingCtx); err != nil {
        _ = db.Close()
        return nil, fmt.Errorf("ping mysql: %w", err)
    }
    return db, nil
}

分配上要留出所有应用副本的总和：例如数据库允许应用使用 300 条连接，10 个副本就不能每个都设置 100。MaxIdleConns 过小会增加建连开销，过大则会让大量长期空闲连接等待回收。

把失效连接重试限制在安全边界

从池里取到已断开的连接时，驱动通常会返回网络断开、连接重置或“server has gone away”一类错误。可以重新取连接重试一次，但必须先问：这次操作是否可能已经在服务端产生副作用？单条只读查询通常更适合有限重试；订单扣库存、支付、写入消息等操作应依靠业务幂等键或事务状态确认，而不是无条件重放。

func QueryUser(ctx context.Context, db *sql.DB, id int64) (string, error) {
    for attempt := 0; attempt 

示例中的 isStaleConnection 省略了驱动类型断言，因此落地时要补上对应 MySQL 驱动的错误码判断，并记录 attempt、耗时和错误类型。不要把语法错误、权限错误、超时或业务校验失败当作失效连接。

观察池状态并处理实际边界

调参不能只看错误日志。周期性记录 DBStats() 中的 OpenConnections、InUse、Idle、WaitCount 和 WaitDuration，可以区分“连接被服务端关闭”和“池容量不足”：前者常在空闲后第一次访问出现，后者表现为等待连接时间持续增加。

最后要记住两个边界：连接池参数不能修复锁等待和慢查询；重试也不能替代事务幂等。把服务端超时、客户端生命周期、请求超时和业务提交状态分别记录，才能判断下一步是改配置、优化 SQL，还是修正业务恢复逻辑。

常见问题

只设置 SetMaxOpenConns 就够了吗？不够。它只限制并发打开连接数，不能主动淘汰已经接近服务端空闲上限的连接；至少还要结合连接寿命和空闲寿命。

把 wait_timeout 调得很大能彻底解决吗？不能。中间网络设备、数据库重启和连接故障仍可能让连接失效；客户端仍需要超时、探活、错误分类和安全的恢复策略。

本文事实依据：MySQL 8.4 Server System Variables 与 Go database/sql 官方文档；示例数值只用于说明配置关系，生产环境请按连接预算和实际观测调整。