db.pingcontext不能当健康检查用，因它只验证连接池中至少一个连接可用，不保证后续db.query所用连接仍有效；mysql服务端wait_timeout到期后会单方面关闭连接，而go客户端可能复用“僵尸连接”，导致ping成功后query仍报错。
db.PingContext 为什么不能当健康检查用
它只验证连接池中至少一个连接可用，不保证后续 db.Query 所用连接仍有效。MySQL 服务端 wait_timeout 到期后会单方面关闭连接，而 Go 客户端可能还在复用这条“僵尸连接”——db.PingContext 成功后，下一次 db.Query 仍可能报 "invalid connection" 或 driver.ErrBadConn。
常见错误现象：
- 高频调用
db.PingContext做“保活”，结果 QPS 上去后错误率反而飙升 - 在
for循环里反复ping，却没配ctx超时，goroutine卡死 - 误以为
ping成功 = 连接池健康，跳过幂等重试逻辑
必须做到：
- 永远用
db.PingContext(ctx)，且ctx带超时（如2 * time.Second） - 不把它放进重试主循环；它不刷新其他连接状态，也不触发重建
- 仅用于启动探活或低频巡检，不能替代错误重试机制
SetConnMaxLifetime 设置不当引发雪崩
这个值控制连接“出生后最多活多久”，和是否空闲无关。若设为 0 或 ≥ 数据库 wait_timeout，旧连接会在服务端关闭后继续被复用，导致批量失效。
MySQL 生产环境 wait_timeout 通常设为 300 秒（5 分钟），但 Go 连接池若未同步调整，就会出问题：
- 设为
0：等于放弃预防，全靠出错重试兜底，风险极高 - 设为
300 * time.Second：刚好踩线，无缓冲余量，网络抖动或服务端延迟关闭就容易触发失败 - 推荐值：
240 * time.Second（4 分钟），留出 60 秒缓冲
PostgreSQL 用户还需同步配置 TCP keepalive 参数：tcp_keepalives_idle、tcp_keepalives_interval、tcp_keepalives_count，否则客户端无法感知服务端断连。
运行时查询失败必须带幂等重试
*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）来不及清理旧连接。更危险的是：若此时数据库短暂不可达，连接池里大量连接会在恢复后集中失效，引发雪崩式重连请求。
排查关键点：
- 查
db.Stats()输出中的InUse和Idle，看是否长期InUse == MaxOpenConns - 确认是否遗漏
rows.Close()或result.Close()，导致连接无法归还池中 - 观察
db.Stats().WaitCount是否持续增长 —— 这说明请求在排队等连接 - 注意
SetMaxIdleConns不宜过大，否则空闲连接堆积，更容易撞上服务端wait_timeout
连接中断问题最棘手的地方不在错误本身，而在于它常以“偶发失败”形式出现，掩盖了 ConnMaxLifetime 与 wait_timeout 的错配、或重试逻辑缺失这类确定性缺陷。一旦发现 "invalid connection"，优先核对这两个值的差值是否小于 60 秒，再检查重试是否覆盖了所有读操作路径。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
