Go 数据库连接池监控为什么不能只看 sql.DB.Stats()
因为 sql.DB.Stats() 返回的是累计值和瞬时快照，比如 OpenConnections 是当前打开数，但没提供历史趋势、拒绝请求次数、等待超时等关键诊断指标。生产环境里连接池打满往往伴随 context deadline exceeded 或 sql: database is closed，但这些错误本身不暴露是池子卡死还是 SQL 慢——得靠监控指标交叉验证。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 必须同时采集
sql.DB.Stats()的WaitCount、WaitDuration、MaxOpenConnections和OpenConnections，它们才是判断是否过载的核心信号 - 不要每秒调用
Stats()多次，它内部有锁；建议 10–30 秒采样一次，用time.Ticker控制节奏 - 注意
WaitCount是自 DB 创建以来的总等待次数，需做差值计算「单位时间等待频次」才能用于告警
用 Prometheus + promhttp 导出 Go 数据库指标最简路径
Go 生态里没有开箱即用的数据库指标自动注册器，得自己把 sql.DB 的状态映射成 Prometheus Gauge 或 Counter。别碰第三方封装库（比如 github.com/ijt/gosql），它们往往藏 bug 且更新滞后。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
prometheus.NewGaugeVec定义指标，标签至少包含db（区分不同 DB 实例）和pool（如mysql/postgres） - 在 HTTP handler 里调用
stats := db.Stats()，然后用gauge.WithLabelValues(...).Set(float64(stats.OpenConnections))更新值 - 导出端点直接挂到
http.Handle("/metrics", promhttp.Handler())，别自己拼字符串响应 - 避免在
http.HandlerFunc里做耗时操作——Stats()很快，但如果你顺手加了db.Ping()就会拖慢整个 metrics 接口
database/sql 连接池参数对监控数值的直接影响
监控值不是凭空产生的，它直接受 SetMaxOpenConns、SetMaxIdleConns、SetConnMaxLifetime 等配置驱动。比如 WaitCount 持续上涨，90% 是因为 MaxOpenConns 设太小，而 IdleCloseCount 飙高往往说明 ConnMaxLifetime 过短导致频繁重建连接。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
-
MaxOpenConns别设成 0（无限制），也别硬写死 100——应按后端数据库最大连接数的 70% 设置，并预留余量 -
MaxIdleConns建议设为MaxOpenConns的 1/2 到 2/3，过大会占内存，过小会导致空闲连接被过早回收，推高OpenCount和CloseCount -
ConnMaxLifetime在云数据库（如 AWS RDS、阿里云 PolarDB）上建议设为 1–3 小时，避开中间件连接中断或防火墙踢连接的窗口期
监控上线后最容易被忽略的三个真实坑
指标跑通不等于能用，很多团队上线后才发现数据对不上、告警乱发、或者根本没覆盖关键故障场景。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 没给
sql.DB加defer db.Close()？那CloseCount永远是 0，OpenCount单向增长——这会让所有连接泄漏类问题彻底隐身 - 用连接池执行 DDL（如
CREATE TABLE）？某些驱动（如pgx）会强制新开连接绕过池子，导致OpenConnections突增但WaitCount不变，监控完全失真 - HTTP metrics 接口没加基础鉴权？内网暴露
/metrics是常见疏漏，尤其当 Prometheus 用 pull 模式时，等于把数据库连接状态全量公开
