database/sql 的 stats() 不能直接当监控用，因其返回自打开以来的累计值，无法反映当前活跃连接或瞬时压力，需周期性采集差值并计算速率，且调用有锁、影响性能。
为什么 database/sql 的 Stats() 不能直接当监控用
因为 sql.DB.Stats() 返回的是自打开以来的累计值，比如 TotalConnections 永远只增不减，无法反映当前活跃连接数或瞬时压力。真实监控需要周期性采集差值、计算速率（如每秒新建连接数）、识别异常漂移（如空闲连接持续归零）。
实操建议：
- 必须自己封装定时采集逻辑，用
time.Ticker每 5–10 秒调一次db.Stats() - 首次采集后，后续每次保存上一周期的
Stats值，与当前做减法算增量 - 重点关注
Idle、InUse、WaitCount和WaitDuration四个字段的环比变化 - 避免在高并发请求路径中直接调用
Stats()——它内部有锁，频繁调用会拖慢查询
如何安全地暴露连接池指标给 Prometheus
Go 生态里最轻量的做法是用 promhttp + 手动注册指标，不引入 sqlx 或 pgx 的专用 exporter。关键点在于：指标必须和 *sql.DB 实例绑定，且更新时加读锁防止竞态。
实操建议：
- 用
prometheus.NewGaugeVec定义带db标签的指标，例如db_pool_idle_connections - 在采集 goroutine 里，先调
db.Stats()，再用Set()更新对应指标，不要用Inc()或Add() - 暴露端点用
http.Handle("/metrics", promhttp.Handler())，别用http.ListenAndServe占用主端口——单独起一个:9101管理端口更稳妥 - 如果应用本身已用
gin或echo，直接把promhttp.Handler()挂到子路由，比如r.GET("/metrics", gin.WrapH(promhttp.Handler()))
WaitCount 突增但 InUse 不高的典型原因
这往往不是数据库慢，而是应用层连接没及时归还。常见于 defer rows.Close() 写错位置、panic 后未执行 defer、或事务里开了 rows 但忘了 Close()。
实操建议：
- 检查所有
db.Query()/db.QueryRow()调用，确保rows.Close()在 defer 中且紧贴查询之后 - 事务内若用
tx.Query()，必须显式rows.Close()；tx.Commit()不会自动关 rows - 临时加日志：在
db.SetMaxOpenConns(5)和db.SetMaxIdleConns(2)下压测，观察WaitDuration是否随请求增多线性上升 - 用
go tool trace抓取运行 trace，过滤database/sql相关事件，看Query到Close的耗时分布
要不要监控底层驱动的连接状态（比如 pgx 的 ConnPool.Stat()）
要，但只在明确用了非 database/sql 标准接口时才启用。比如用 pgxpool 替代 sql.Open，它的 Stat() 返回的是实时连接池快照，字段更细（如 AcquiredConns、ConstructingConns），比 sql.DB.Stats() 更适合诊断连接建立阻塞。
实操建议：
- 如果项目混用
sql.DB和pgxpool.Pool，监控代码里得区分类型断言，不能硬转 -
pgxpool.Stat()的ConstructingConns > 0持续超过 2 秒，说明 DNS 解析、TLS 握手或服务端 accept 队列满，需查网络或 DB 配置 - 不要同时上报
sql.DB.Stats()和pgxpool.Stat()的同名指标（如idle），容易在 Grafana 里混淆——用不同指标名，比如加前缀pgx_pool_
真正难的是把瞬时指标和业务请求链路对齐。比如某次 WaitDuration 尖刺，得能快速定位到是哪个 HTTP handler 或 cron job 触发的——这需要在采集时带上上下文标签，而不是只盯连接池本身。
