go的database/sql连接池不主动探测空闲连接状态，仅在归还时关闭超时连接；需配对设置setmaxopenconns、setmaxidleconns和setconnmaxlifetime，并辅以低频pingcontext定时探测空闲连接有效性。
database/sql连接池根本不管空闲连接是否还活着
Go 的 database/sql 连接池不会主动探测空闲连接状态。它只在连接归还时按需关闭超时连接，从不扫描或 ping 空闲连接。这意味着：网络中断、DB 重启、防火墙 kill 连接后，那些“看着还在线”的连接仍会留在池里，直到某次 db.Query() 拿到它并直接报 "i/o timeout" 或 "connection reset by peer"。
常见错误是以为 db.SetConnMaxLifetime(5 * time.Minute) 就能保活——它只控制连接“出生后最多活多久”，不解决“中途断连”问题；db.Ping() 适合启动校验，但高频调用会压垮 DB，且无法覆盖具体将被取出的那个连接。
- SetConnMaxLifetime 到期后连接才被销毁，不是实时探活
- 空闲连接数（
db.Stats().Idle）可能长期 >0，但其中部分已失效 - MySQL 的
wait_timeout默认 8 小时，但生产常设为 300 秒；若 Go 不设 MaxLifetime 或设得 ≥300 秒，必然复用 stale 连接
用低频 PingContext 主动清理疑似失效连接
真正可行的保活，是在应用层加一个轻量定时任务，只对少量空闲连接做探测，既避开全量扫描开销，又能在失效前主动清理。
关键点是：只查 db.Stats().Idle，只挑 1–2 个连接 ping，用带超时的 context.WithTimeout(ctx, 2*time.Second) 包裹 db.PingContext()，失败后不用手动 Close() —— 连接池会在下次归还时自动丢弃它。
- 频率建议 30–60 秒一次（示例用 45 秒），太高会增加 DB 压力
- 必须检查
stats.Idle > 0再执行 ping，避免无连接可测时空跑 - ping 失败只需记录日志或触发告警，不必立即重试或重建连接池
- 不要在每次 HTTP 请求前 ping，那会拖慢响应，且违背“低频、后台、非阻塞”原则
连接池参数必须成对设置，单点优化没用
只调 SetConnMaxLifetime 或只改 SetMaxOpenConns 都不能解决闲置断连。这三个参数必须协同：
-
SetMaxOpenConns(20)：防打爆 DB，值应 ≤ DBmax_connections× 0.8 -
SetMaxIdleConns(10)：控制空闲连接上限，推荐设为 MaxOpenConns 的 1/2～2/3 -
SetConnMaxLifetime(240 * time.Second)：留出 60 秒缓冲，确保早于 MySQLwait_timeout生效
漏掉任意一项，都可能导致连接堆积、复用 stale 连接或突发建连风暴。比如 SetMaxIdleConns 不设，空闲连接可能长期滞留；SetConnMaxLifetime 设为 0，等于放弃预防，全靠出错兜底。
查询失败时该不该重试，取决于 SQL 类型和上下文
遇到 "invalid connection" 或 driver.ErrBadConn 时，database/sql 默认不重试，也不换连接。是否重试，必须由业务逻辑判断：
- SELECT 类只读操作：可安全重试，前提是没修改本地状态
- INSERT/UPDATE/DELETE：不能盲目重试，必须结合幂等 key、事务状态校验或服务端唯一约束
- 重试必须用
context.WithTimeout控制总耗时（建议 ≤2 秒），并配指数退避（100ms → 200ms → 400ms…） - 只捕获明确连接类错误：
driver.ErrBadConn、net.OpError、"connection refused"、"timeout"；SQL 语法错、权限错不重试
最危险的是封装一个通用 SafeQuery 自动重试所有 SQL——它会把 WHERE id = ? 写成 WHERE id == ? 这种语法错也反复重试，掩盖真实问题，甚至导致重复写入。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
