sql.DB连接池默认参数极保守，必须结合微服务并发、实例数、MySQL配置等手动调优：SetMaxOpenConns建议设为DB最大连接数×0.7÷实例数，SetMaxIdleConns不宜超其1/3，且必须配SetConnMaxLifetime（5–30分钟）和SetConnMaxIdleTime（5–15分钟）防stale连接，并通过db.Stats()持续监控WaitCount等指标。
sql.DB 的连接池不是“开箱即用就高效”的——它默认参数极保守（SetMaxOpenConns(0) 表示无限制，SetMaxIdleConns(2)），直接跑在微服务里大概率会出连接耗尽、响应毛刺或数据库被打挂的问题。优化必须结合业务特征手动调参，不能只抄网上的固定数值。
为什么微服务场景下连接池容易出问题
微服务通常并发高、实例多、生命周期短，而 MySQL 本身对连接数敏感（尤其受 max_connections 和操作系统文件描述符限制）。多个微服务实例各自维护独立连接池，若每个都设 SetMaxOpenConns(100)，而数据库只配了 200 个连接，瞬间就打满。
- 服务扩缩容时，连接池不会自动缩容，旧实例残留的空闲连接可能长期不释放
- HTTP 请求短平快，但
db.Query()调用后连接归还延迟（比如没 deferrows.Close()）会导致连接卡在 busy 状态 - 数据库侧重启或网络抖动后，连接池里的 stale 连接不会自动剔除，后续请求会卡住直到超时
SetMaxOpenConns 和 SetMaxIdleConns 怎么设才合理
这两个值不是越大越好，也不是越小越省资源，得看你的服务 QPS、平均 SQL 耗时、MySQL 实例规格和部署拓扑。
-
SetMaxOpenConns建议设为：MySQL 单实例max_connections× 0.7 ÷ 微服务实例数（向上取整）。例如 DB 配了 300 连接，你有 6 个 Pod，则设 35～40；别硬套“CPU 核数 × 2 + 磁盘数”这种通用公式 -
SetMaxIdleConns不宜超过SetMaxOpenConns的 1/3，否则空闲连接堆积却无法复用（因为活跃连接已占满上限），反而浪费资源。设为 5～10 通常够用 - 如果服务是突发流量型（如秒杀），可临时放宽
SetMaxOpenConns，但必须配合SetConnMaxLifetime缩短生命周期，避免长连接堆积
SetConnMaxLifetime 和 SetConnMaxIdleTime 必须配
不设这两个，连接池会在后台持续持有失效连接，尤其在数据库重启、LB 切换或网络分区后，大量请求会卡在 driver.Conn.Begin() 或 net.Conn.Write 上，表现为偶发超时或 context deadline exceeded。
-
SetConnMaxLifetime推荐 5～30 分钟。太短（如 1 分钟）会导致频繁重建连接；太长（如 2 小时）会让 stale 连接存活太久。MySQL 默认 wait_timeout 是 28800 秒（8 小时），设比它小一半比较安全 -
SetConnMaxIdleTime推荐 5～15 分钟。它控制空闲连接最大保留时间，避免连接池里堆着一堆“看起来可用但实际已被 DB 关闭”的连接 - 注意：
SetConnMaxIdleTime在 Go 1.19+ 才生效，低版本只能靠SetConnMaxLifetime兼容兜底
连接池状态监控不能只靠日志
光靠 db.Ping() 检查连通性没用，它只验证当前是否有可用连接，不反映池内真实水位。线上必须采集 db.Stats() 并暴露 Prometheus 指标。
立即学习“go语言免费学习笔记（深入）”；
- 关键指标：
OpenConnections（当前打开总数）、Idle（当前空闲数）、WaitCount（等待连接的累计次数）、WaitDuration（总等待时长） - 如果
WaitCount持续上涨，说明SetMaxOpenConns设低了；如果Idle长期接近SetMaxIdleConns且OpenConnections波动小，说明池子偏大，可适当下调 - 不要在每次 HTTP 请求里调
db.Stats()，它带锁；建议每 10～30 秒采样一次，聚合后上报
WaitDuration 和 DB 侧的 Threads_connected 是否匹配。参数调完不监控，等于没调。 
