MySQL 连接池空闲连接失效 怎样处理

MySQL 连接池空闲连接失效，通常不是“连接池坏了”，而是连接在空闲期间先被 MySQL、代理或网络设备关闭，应用下一次复用时才发现。处理这类问题要先对齐时间边界，再让应用主动回收比外部更早过期的连接。

先判断：到底是谁让连接失效

如果接口在持续流量下正常，服务空闲一段时间后第一条 SQL 才报“broken pipe”“connection reset”或“server has gone away”，优先怀疑空闲连接的生命周期。MySQL 的 wait_timeout 针对非交互连接，服务端在这段时间没有活动后可以主动关闭会话；云数据库前的代理、负载均衡和防火墙也可能使用更短的空闲清理时间。

先把现象分成三层：MySQL 是否已经关闭会话，网络中间层是否丢弃 TCP 状态，应用池是否把过期连接保留得太久。不要只把 MaxOpenConns 调大，它只限制并发打开数，不能延长或修复已经失效的连接。

先检查 MySQL 和连接池的时间边界

在数据库侧查看当前会话实际使用的变量，不要只看配置文件中的预期值：

-- 查看非交互连接的空闲关闭阈值，以及当前连接的会话值
SHOW GLOBAL VARIABLES LIKE 'wait_timeout';
SHOW SESSION VARIABLES LIKE 'wait_timeout';

-- 用于确认是否存在大量长期 Sleep 会话
SHOW STATUS LIKE 'Threads_connected';

再对照应用池的最大空闲时长、连接最大生命周期和外部代理的 idle timeout。实用原则是：应用主动回收时间要短于最短的外部清理时间，并留出网络抖动和请求排队的余量；如果外部阈值未知，先用指标和日志观测，不要随意修改 MySQL 全局变量。

用连接池参数提前回收，而不是等错误出现

以 Go 的 database/sql 为例，sql.DB 是连接池句柄而不是一条固定连接。下面的配置重点不在某个固定分钟数，而在于把回收策略显式写出来，并给每次健康检查设置边界：

package main

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

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

func openDB(dsn string) (*sql.DB, error) {
    // Open 只创建池句柄；PingContext 才会在启动阶段验证连通性。
    db, err := sql.Open("mysql", dsn)
    if err != nil {
        return nil, err
    }

    // 让应用在外部空闲清理之前淘汰连接；数值要按现场阈值调整。
    db.SetMaxOpenConns(30)
    db.SetMaxIdleConns(10)
    db.SetConnMaxIdleTime(5 * time.Minute)
    db.SetConnMaxLifetime(30 * time.Minute)

    ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
    defer cancel() // 避免健康检查的定时器持续占用资源。
    if err := db.PingContext(ctx); err != nil {
        db.Close() // 启动失败时释放已经创建的池资源。
        return nil, err
    }
    return db, nil
}

func query(ctx context.Context, db *sql.DB, id int64) error {
    // 查询也要有超时；连接失效和 SQL 执行过慢都不能无限等待。
    _, err := db.ExecContext(ctx, "UPDATE accounts SET touched_at = NOW() WHERE id = ?", id)
    if err != nil {
        log.Printf("database operation failed: %v", err)
    }
    return err
}

SetConnMaxIdleTime 只处理“闲置多久”，SetConnMaxLifetime 处理“这条连接从建立起活了多久”。两者都可能在下次复用前惰性关闭，不能当作每秒定时清理器。SetMaxIdleConns(0) 会让池不保留空闲连接，但会增加频繁建连成本，通常应结合流量而不是一刀切。

用指标确认修复真的生效

发布配置后，观察 db.Stats()：Idle 是否符合预期，WaitCount 是否因池太小持续上涨，MaxIdleTimeClosed 和 MaxLifetimeClosed 是否按策略增长。启动探活只说明此刻能连通，不代表每次业务查询都不会遇到网络中断。

// 定期记录池状态，帮助区分“连接失效”和“池排队”。
stats := db.Stats()
log.Printf("open=%d in_use=%d idle=%d wait=%d idle_closed=%d lifetime_closed=%d",
    stats.OpenConnections, stats.InUse, stats.Idle, stats.WaitCount,
    stats.MaxIdleTimeClosed, stats.MaxLifetimeClosed)

如果只有空闲后的第一条请求失败，缩短应用回收时间或开启驱动的存活检查更有针对性；如果 WaitCount 与 WaitDuration 持续上涨，应检查慢 SQL、事务未提交、Rows 未关闭和连接数上限。不要用无限重试掩盖这些问题，写操作重试还必须先确认幂等性。

常见问题

把 wait_timeout 调大就能解决吗？

不一定。它只能改变 MySQL 侧的非交互空闲关闭阈值，代理、防火墙和客户端生命周期仍可能更短；而且长期保留大量空闲会话会占用服务端资源。

为什么 Ping 成功，下一条 SQL 仍然失败？

Ping 只验证检查发生时的连接状态，检查后到业务查询之间仍可能发生网络中断。应给真实查询设置上下文超时，并记录具体错误和池指标。

SetConnMaxIdleTime 和 SetConnMaxLifetime 该怎么选？

前者解决空闲过久，后者限制连接总年龄。若外部设备会清理空闲连接，优先设置一个更短的空闲上限；若连接长期复用后出现会话状态或网络漂移，再补生命周期上限。