db.Ping() 返回 "driver: bad connection" 或 "sql: database is closed"；前者表示连接池中连接失效但 *sql.DB 仍存活，后者说明 db 已被显式关闭，需重建实例。
MySQL连接断开后，db.Ping() 返回什么错误？
Go 的 database/sql 包本身不维护“长连接”概念，db.Ping() 实际是向数据库发起一次轻量探测（类似执行 SELECT 1）。如果连接池中所有连接都已失效（比如 MySQL 服务重启、网络中断、wait_timeout 触发），db.Ping() 会返回类似 "sql: database is closed" 或更常见的 "driver: bad connection" —— 注意，后者不是网络层超时错误，而是连接已不可用但 *sql.DB 对象仍存活的典型表现。
别依赖 err == nil 就认为后续查询一定成功；必须对每次 db.Query() / db.Exec() 的 error 单独判断，因为连接可能在 Ping 之后、实际查询之前就断了。
-
db.Ping()失败 ≠ 连接池彻底不可用，可能是部分连接失效，下次Query()可能自动重试新连接 - 若
db.Ping()返回"sql: database is closed"，说明你调用了db.Close()或程序逻辑误关了它，此时必须重建*sql.DB - 真正需要“守护”的，是连接池健康度下降、频繁报
"driver: bad connection"且持续数秒以上的情况
如何用 time.Ticker 安全轮询而不阻塞主线程？
用 time.Ticker 启动一个独立 goroutine 做周期性健康检查，是最轻量也最可控的方式。关键点在于：不能让轮询逻辑阻塞，也不能让多次 Ping 累积并发请求。
- 每次轮询前加
select配合ctx.Done()，确保能响应关闭信号 - 给
db.Ping()加超时控制，例如用ctx.WithTimeout(ctx, 2*time.Second)，避免卡死在网络抖动上 - 连续失败 3 次再触发重连动作，避免瞬时抖动误判；失败计数器需用
sync.Mutex或atomic保护 - 重连操作本身要串行化：用
sync.Once或互斥锁防止多个 goroutine 同时重建*sql.DB
示例片段：
立即学习“go语言免费学习笔记（深入）”；
go func() {
ticker := time.NewTicker(10 * time.Second)
defer ticker.Stop()
failCount := 0
for {
select {
case <-ctx.Done():
return
case <-ticker.C:
if err := db.PingContext(ctx); err != nil {
failCount++
if failCount >= 3 {
log.Warn("MySQL health check failed 3 times, attempting reconnect...")
if newDB, err := reconnectMySQL(dsn); err == nil {
atomic.StorePointer(&dbPtr, unsafe.Pointer(newDB))
failCount = 0
}
}
} else {
failCount = 0
}
}
}
}()重连时为什么不能直接 db.Close() + sql.Open()？
直接调用旧 *sql.DB 的 Close() 是危险的：正在执行的查询可能被中断，导致事务未提交、资源泄漏，甚至引发 panic（如 panic: sql: Rows are closed）。正确做法是“无缝切换”——新建连接池，等新连接通过健康检查后，再原子替换全局引用，让旧连接池自然耗尽。
- 新
*sql.DB必须设置合理参数：SetMaxOpenConns()、SetMaxIdleConns()、SetConnMaxLifetime()，否则新池可能比旧池更脆弱 - 替换引用时用
atomic.StorePointer+atomic.LoadPointer（配合unsafe.Pointer）或sync/atomic.Value，避免读写竞争 - 旧
*sql.DB不要主动Close()，让它随最后一次查询完成自动释放连接；可选地，在确认新池稳定运行 30 秒后，再调用其Close() - 注意 DSN 中的
timeout、readTimeout、writeTimeout参数，它们影响重连初期的建连成功率
生产环境必须处理的三个隐藏陷阱
很多实现只关注“连得上”，却在真实部署中翻车：
- MySQL 的
max_connections限制：每次重连都新建连接池，若未调用旧池的Close()，连接数会线性增长直至打满服务端上限 - 事务上下文丢失：如果业务代码把
*sql.Tx存在 context 或全局变量里，连接切换后这些 Tx 对象立即失效，后续Commit()必 panic - 连接池内部状态不同步：
sql.Open()返回的*sql.DB初始时连接数为 0，首次查询才 lazy 初始化，所以重连后立刻做 Ping 可能误判“健康”，应额外加一次空查询（如db.QueryRow("SELECT 1")）确认可用
守护函数不是加个 Ping 就完事；它得理解连接池生命周期、事务边界、以及 MySQL 服务端配置的联动影响。最稳的做法，是把重连决策权交给业务层 —— 监控到连续失败时发告警，由运维触发滚动重启，而非全自动切换。
