MySQL 连接池空闲断开后应用为什么出现坏连接

这种现象通常不是“连接池创建了一个坏连接”，而是 MySQL 已经按空闲超时关闭连接，应用池仍把它当作可复用连接保存。下一次请求借到它并发送 SQL 时，才出现 MySQL server has gone away、invalid connection 或驱动对应的断连错误。

处理顺序很明确：先查 wait_timeout 和中间网络设备的空闲回收时间，再把应用池的空闲回收设得更短；启动时用 PingContext 做可达性检查；运行中的自动重试只允许覆盖可安全重放的读操作，不能把事务写入一律重发。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/

先把“空闲断开”和“执行中断开”分开

先在 MySQL 会话中查看当前值，不要直接照搬配置文件里的数字：

-- 查看当前会话真正使用的空闲超时值
SHOW SESSION VARIABLES LIKE 'wait_timeout';

-- 同时看全局默认值，便于判断新连接会继承什么
SHOW GLOBAL VARIABLES LIKE 'wait_timeout';

MySQL 8.4 文档说明，wait_timeout 是非交互连接等待活动的秒数，默认值为 28800；线程启动时，会话值从全局 wait_timeout 或交互连接对应的值初始化。应用连接一般属于非交互连接，所以要以应用实际会话为准。

如果连接空闲很久后，第一次查询才报错，优先检查这条链路。若查询已经执行了很长时间才断开，则还要调查网络读写超时、代理和 SQL 执行耗时，不能只改连接池。

让应用池先于 MySQL 淘汰空闲连接

以 Go database/sql 为例，池子本身不等于单条连接；SetConnMaxIdleTime 控制连接在池中闲置多久，过期连接会在再次使用前被惰性关闭。生产值应根据服务端、代理、负载均衡器中最短的空闲限制来定，并留出余量。

package main

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

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

    // 空闲回收要早于 MySQL 或代理的最短空闲断开时间。
    db.SetConnMaxIdleTime(25 * time.Minute)
    // 定期轮换连接，避免连接跨越网络设备或证书生命周期。
    db.SetConnMaxLifetime(2 * time.Hour)
    // 先限制池规模，再根据数据库容量做压测调整。
    db.SetMaxIdleConns(8)
    db.SetMaxOpenConns(32)

    // Open 只创建池，不保证此刻已经连通数据库。
    ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
    defer cancel()
    if err := db.PingContext(ctx); err != nil {
        db.Close() // 启动失败时释放已经创建的池。
        return nil, err
    }
    return db, nil
}

func main() {
    if _, err := openDB("user:pass@tcp(127.0.0.1:3306)/app"); err != nil {
        log.Fatal(err)
    }
}

示例数字只是演示参数关系，不是通用答案。比如 MySQL、云数据库、NAT 或代理中任一层的空闲回收小于 25 分钟，就要把应用值继续下调。SetConnMaxLifetime 解决的是连接年龄，不是空闲超时；两者应分别设置。

用池统计和错误时间线确认修复有效

不要只看一次 PingContext 就宣布修复。它适合启动或主动检查，不能替代运行中每次查询的错误记录。建议把请求时间、SQL 类型、是否事务、连接池统计和错误类型放在同一条观测链路中：

// 每个采样窗口记录池状态，观察是否频繁新建连接或等待连接。
stats := db.Stats()
log.Printf("open=%d in_use=%d idle=%d wait=%d wait_duration=%s",
    stats.OpenConnections,
    stats.InUse,
    stats.Idle,
    stats.WaitCount,
    stats.WaitDuration,
)

如果“空闲一段时间后第一条请求失败”的比例下降，同时新建连接数短暂上升，这是应用主动淘汰旧连接后的正常代价。若仍然出现断连，要继续检查代理、网络设备和服务端重启，而不是无限缩短池参数。

重试只放在可证明安全的位置

连接坏了，驱动可能在下一次借连接时建立新连接，但业务层是否重试是另一件事。对只读、幂等、尚未向用户返回结果的查询，可以在识别连接类错误后最多补一次；对 INSERT、扣库存、发消息或事务提交后的未知状态，不应凭错误字符串自动重放。

常见问题

把 wait_timeout 调大就能彻底解决吗？

不能。它只能改变 MySQL 的一层空闲边界，代理、负载均衡器、NAT 和网络抖动仍可能先关闭连接。优先让应用池在最短边界前主动回收。

为什么连接池参数已经设置，仍偶发坏连接？

连接回收通常是惰性的，参数只能降低概率；还要检查连接是否被外部设备关闭、是否有长事务或执行中读写超时，并按错误时间线定位。

能不能每次查询前都 Ping？

通常不建议把一次额外 Ping 变成所有请求的固定开销。更合理的是配置池回收、启动检查、错误分类和有限重试；高风险写入则使用业务幂等键或补偿流程。