健康检查函数必须使用 db.pingcontext，它专为探测连接池健康设计，复用空闲连接发送轻量 ping 命令，需配合 context.withtimeout 控制超时，失败后应记录日志并触发轻量操作促连接池自动恢复，严禁重复 sql.open。
健康检查函数必须用 db.PingContext，不能只靠 db.Exec 或 db.Query
很多开发者误以为执行一条空查询（如 SELECT 1）就能判断连接是否可用，但这样会绕过连接池底层状态校验。Go 的 database/sql 包中，db.PingContext 是唯一专为探测连接池健康设计的机制——它会尝试从连接池获取一个连接并发送轻量级 ping 命令（对 PostgreSQL 是 PING，MySQL 是 COM_PING），不占用事务或语句资源。
常见错误是直接调用 db.Ping() 而忽略上下文超时控制，导致健康检查卡死。必须配合 context.WithTimeout：
ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
defer cancel()
err := db.PingContext(ctx)
if err != nil {
return false, err
}
-
db.PingContext不会新建连接，只复用空闲连接或触发连接池内部探活逻辑 - 超时时间建议设为 1–3 秒：太短易误判（尤其高延迟网络），太长拖慢服务启动或探针响应
- 若返回
driver.ErrBadConn，说明该连接已失效，连接池会自动标记并后续丢弃
自动重连不能在 db.PingContext 失败后直接调用 sql.Open
重连不是“关掉再开”，而是要复用原有 *sql.DB 实例的配置与连接池参数。直接 sql.Open 新实例会导致旧连接泄漏、连接数失控、甚至事务上下文错乱。
正确做法是让连接池自行恢复：只要确保 *sql.DB 实例未被 Close()，且连接字符串和驱动无变化，失败后的下一次 Query/Exec 就会自动新建连接。你只需做两件事：
- 在健康检查失败后，记录日志并触发一次轻量级操作（如
db.QueryRowContext(ctx, "SELECT 1")），促使连接池重建连接 - 避免在重连逻辑里重复调用
sql.Open—— 这个函数本就不该被反复调用，应只在应用初始化时执行一次 - 如果数据库地址动态变更（如故障转移），才需重建
*sql.DB，此时必须先db.Close()再sql.Open，否则旧连接持续占用资源
连接池参数直接影响重连行为和健康检查稳定性
*sql.DB 的 SetMaxOpenConns、SetMaxIdleConns 和 SetConnMaxLifetime 不只是性能调优项，它们决定连接何时被回收、是否复用、以及探活是否有效。
-
SetMaxIdleConns(5)过低会导致空闲连接快速释放，下次请求被迫新建连接，放大网络抖动影响 -
SetConnMaxLifetime(0)（默认值）意味着连接永不过期，但在云环境或 LB 后端重启时，可能保留已断开的“僵尸连接”；建议设为 5–30 分钟 -
SetMaxOpenConns若设得太小（如 1），所有请求排队等待，健康检查也会阻塞，看起来像“连不上”，实则是连接池耗尽 - PostgreSQL 驱动（
lib/pq）和 MySQL 驱动（go-sql-driver/mysql）对connect_timeout等 DSN 参数处理不同，务必在连接字符串里显式指定，例如：user:pass@host/db?connect_timeout=3s
健康检查周期选 5 秒还是 30 秒？取决于下游数据库的故障恢复速度
高频检查（如 1 秒）会增加数据库负载，尤其当连接池空闲时，PingContext 仍可能触发新连接建立；低频检查（如 5 分钟）则无法及时发现中间网络闪断或数据库短暂不可用。
推荐策略是分层探测：
- 就绪探针（readiness probe）：每 5 秒调用一次
db.PingContext，失败连续 3 次标记为不可用 - 存活探针（liveness probe）：每 30 秒执行一次带简单业务语义的检查，如
SELECT COUNT(*) FROM health_check_table，验证连接 + 权限 + 表结构 - 应用启动时强制一次健康检查，失败立即 panic 或退出，避免带病上线
真正容易被忽略的是：健康检查本身不该成为单点瓶颈。不要把多个数据库的检查串行执行，也不要共享同一个 context.Context 超时——每个检查应独立控制超时与取消。
