db.PingContext不是连接健康检查的银弹，仅验证连接池中至少一个连接可用，无法保证后续Query成功；需配合SetConnMaxLifetime、幂等重试及合理连接池配置。
db.PingContext 不是连接健康检查的银弹
很多人以为启动时 db.PingContext 成功，后续就高枕无忧了。其实它只验证连接池里「至少一个」连接可用，而这个连接可能刚被 MySQL 服务端因 wait_timeout 关闭，只是客户端还没感知到 —— 下次 db.Query 仍会报 invalid connection 或 driver: bad connection。更糟的是，db.Ping() 本身不带 context 控制，超时后还会继续阻塞。
- 永远用
db.PingContext(ctx)替代db.Ping()，尤其在重试循环中 - 不要把 Ping 当成“保活”手段：它不刷新连接池里其他连接的状态
- Ping 成功 ≠ Query 成功，只是降低首次失败概率
SetConnMaxLifetime 必须比 wait_timeout 小
MySQL 默认 wait_timeout = 28800（8 小时），但生产环境常调低到 300 秒（5 分钟）。如果 Go 连接池里的连接存活时间超过这个值，服务端已关闭、客户端却还在复用，就会触发失效错误。关键不是“空闲多久”，而是“出生后最多活多久”。
-
db.SetConnMaxLifetime(240 * time.Second)是稳妥值，留出 60 秒缓冲 - 设为 0 表示永不过期 → 直接放弃预防，靠出错重试兜底，风险极高
- 该设置对连接池中所有连接统一生效，与是否 idle 无关
- PostgreSQL 用户注意：
tcp_keepalives_idle等参数也需协同调整
运行时查询失败必须带幂等重试
*sql.DB 内置的重试只在 driver.ErrBadConn 场景下触发，且最多 10 次硬编码重试（不可配置），遇到网络抖动、主从切换或 DNS 变更时完全无效。你得自己控制重试逻辑，但不能无脑重放写操作。
- 只对
SELECT、GET类幂等操作重试；INSERT/UPDATE/DELETE需结合业务 idempotency key 或事务状态校验 - 用
context.WithTimeout包裹整个重试流程，避免卡死 - 推荐指数退避：第一次 100ms，第二次 200ms，第三次 400ms… 总重试时间不超过 2 秒
- 捕获明确错误类型：
driver.ErrBadConn、net.OpError、“connection refused”、“timeout” —— 其他如认证失败、SQL 语法错不重试
并发突增时 MaxOpenConns 会放大连接失效影响
当 QPS 突增，db.SetMaxOpenConns(20) 被打满，所有连接都在高频使用，老化机制（ConnMaxLifetime）来不及清理旧连接。更危险的是：若此时数据库短暂不可达，连接池里大量连接会在恢复后集中失效，引发雪崩式重连请求。
- MaxOpenConns 值要按压测结果设，别盲目照搬文档推荐值（如 25）
- 配合
db.SetMaxIdleConns(10)控制空闲连接上限，避免堆积 stale 连接 - 高并发服务建议开启连接池指标暴露（如 Prometheus），监控
sql_open_connections和sql_idle_connections - 别依赖“连接池自动恢复”：database/sql 的 fallback 重试发生在 query 层，已无法控制上下文和语义
真正难处理的不是单次断连，而是连接池里一批连接在毫秒级内集体过期又同时被取出 —— 这时候重试逻辑的退避节奏、上下文超时边界、以及是否幂等，全都会暴露出来。
