MySQL 连接池空闲连接被断开后如何恢复

MySQL 连接池里的空闲连接被断开，最稳妥的恢复方式不是把 wait_timeout 无限调大，而是让应用在服务端之前主动淘汰连接，并把真正的坏连接交给驱动和连接池重新建立。先查清楚断开方，再设置 ConnMaxIdleTime、ConnMaxLifetime，最后根据读写是否可能产生副作用决定要不要重试。

先判断：到底是谁关闭了空闲连接

MySQL 8.4 文档中，wait_timeout 表示服务器在非交互连接没有活动时等待的秒数，默认值是 28800，但生产环境可能在全局配置、会话初始化、代理或云数据库侧改过。连接池报错如果总是在“闲置一段固定时间后的第一次查询”出现，优先怀疑这条链路，而不是先扩大连接池。

先在问题连接对应的会话里查看实际值：

-- 查看当前会话和全局值，避免只看配置文件中的预期值
SHOW SESSION VARIABLES LIKE 'wait_timeout';
SHOW GLOBAL VARIABLES LIKE 'wait_timeout';

再对照错误日志中的时间间隔。如果应用前面还有负载均衡器、NAT、防火墙或数据库代理，还要找它们的 idle timeout；真正生效的是这些链路中最短的那一个。mysqladmin ping 只能说明一次新的管理连接能否联系到服务端，不能证明池中每条旧连接都仍然可用。

让连接池先淘汰，而不是把坏连接交给业务

如果使用 Go 的 database/sql，可以把池的生命周期设置得比基础设施的最短空闲限制更短。下面的数值只是示例，不能脱离你的 MySQL、代理和流量模型直接照搬：

package dbpool

import (
    "database/sql"
    "time"
)

func tune(db *sql.DB) {
    // 连接上限要纳入实例、账号和其他服务的总连接预算。
    db.SetMaxOpenConns(50)
    // 空闲连接过多会增加被服务端或代理回收后的失效概率。
    db.SetMaxIdleConns(10)
    // 让客户端在基础设施之前回收长期空闲连接；这是示例值。
    db.SetConnMaxIdleTime(5 * time.Minute)
    // 定期更换长期连接，覆盖证书、网络设备和服务端重启等场景。
    db.SetConnMaxLifetime(30 * time.Minute)
}

SetConnMaxIdleTime 和 SetConnMaxLifetime 的关闭可能是延迟发生的：连接在再次使用前才被发现到期并清理。因此它们降低的是“从池中拿到太老连接”的概率，不是对网络故障的绝对保证。若最短基础设施空闲超时只有 2 分钟，应用池就不应设置 5 分钟的空闲时间。

健康检查该放在哪里，断线后怎么恢复

应用启动、就绪探针或运维健康检查可以使用带超时的 PingContext。它适合确认数据库是否可通信，也能在服务刚恢复时尽早暴露连接问题；但每次业务查询前都 Ping 会额外增加往返，并不能消除 Ping 与真正查询之间的竞态。

func checkDB(ctx context.Context, db *sql.DB) error {
    // 健康检查必须有上限，避免数据库异常时拖住探针线程。
    pingCtx, cancel := context.WithTimeout(ctx, time.Second)
    defer cancel()
    return db.PingContext(pingCtx)
}

func poolSnapshot(db *sql.DB) sql.DBStats {
    // 记录空闲数、使用数和等待时间，辅助判断是坏连接还是池容量不足。
    return db.Stats()
}

真正执行查询时，驱动如果明确返回“坏连接”，database/sql 才有机会换一条新连接重试；普通网络错误、语句错误或事务结果不确定时，不要在业务层把同一 SQL 无条件再发一次。恢复顺序通常是：让当前操作返回错误、关闭或回滚当前事务、由连接池丢弃失效连接，再让下一次安全请求取得新连接。

读请求可以重试，事务和写请求先确认结果

“断线后自动重连”不等于“原请求自动成功”。一个查询在网络断开前可能已经到达 MySQL，也可能只是在发送阶段失败。对普通 SELECT，可以在明确识别为连接失效、上下文仍有余量、且重试次数为 1 的前提下重试；最好给查询增加请求 ID 和日志字段，方便判断是否出现重复读取或超时。

对 INSERT、扣库存、发送消息或带副作用的存储过程，先把结果视为“未知”，不要直接重放。可用唯一键、幂等业务号、事务状态表或结果查询确认是否已经提交；确认未提交后再由上层决定是否重新执行。事务里的连接已经断开时，后续语句也不应继续使用原事务对象。

常见问题

把 MySQL 的 wait_timeout 调得很大就能解决吗？

不一定。代理、防火墙、云网络和数据库重启仍可能关闭连接；更重要的是，超大连接生命周期会让旧连接在池里存得更久。优先让客户端生命周期小于最短基础设施限制。

是否应该每次取连接前执行 SELECT 1？

通常不应把它作为所有请求的固定前置步骤。它增加一次往返，而且检查后连接仍可能立刻断开。更合适的做法是生命周期回收、健康检查和针对明确坏连接的有限恢复。

为什么重试后仍然报错？

可能是服务端仍不可用、池已耗尽、超时配置仍比代理长，或者业务层重试的是一个结果不确定的事务。结合 DBStats、错误时间间隔和 MySQL 连接日志一起判断，不要只看重试次数。

排查完成后，至少保留三类指标：池的 InUse、Idle、WaitCount，断线错误的时间间隔，以及 MySQL 的连接和超时配置。这样下次再出现“空闲连接被断开”，就能快速判断是参数不匹配、基础设施中断，还是一次不该自动重放的业务操作。