调用 db.stats() 定期获取 sql.dbstats 快照，其中 openconnections、idle、waitcount、waitduration 等字段是排查连接泄漏和瓶颈的关键指标，需结合 prometheus 正确映射为 gauge 或 counter。
怎么拿到 *sql.DB 的实时连接池指标
Go 标准库的 database/sql 包提供了 DB.Stats() 方法，它返回一个 sql.DBStats 结构体，里面全是当前连接池的快照数据。不是回调、不是订阅，就是一次调用一次快照——所以监控时得自己定时拉取。
常见错误是以为调用一次就能持续监听：比如在 init 里调一次就不管了，结果指标永远停留在启动那一刻。正确做法是用 time.Ticker 定期调用，或集成进你的 metrics 上报循环里。
-
DB.Stats()是线程安全的，可并发调用，无需加锁 - 返回的
sql.DBStats字段全是只读值，不带指针，直接拷贝即可 - 注意字段含义：
OpenConnections是当前已打开的连接数（含空闲+正在用），Idle是空闲连接数，InUse=OpenConnections - Idle - 如果
WaitCount持续增长，说明有 goroutine 在等空闲连接，大概率是MaxOpenConns设太小或 SQL 执行太久没释放
哪些字段对排查连接泄漏最关键
连接泄漏最典型的表象不是报错，而是 OpenConnections 缓慢上涨、Idle 趋近于 0、WaitCount 和 MaxOpenConnections 差距越来越大。这时候光看日志没用，得盯这几个字段：
-
MaxOpenConnections：你代码里设的上限，不是数据库服务端限制；设为 0 表示无上限（危险！） -
OpenConnections：真实打开的连接数，超过MaxOpenConns就会阻塞新请求 -
WaitCount：累计等待过空闲连接的次数，突增说明连接池成了瓶颈 -
WaitDuration：所有等待耗时总和，除以WaitCount可算平均等待延迟 -
MaxIdleClosed和MaxLifetimeClosed：非零说明有连接被主动关掉，可能是SetMaxIdleConns或SetConnMaxLifetime在起作用
导出到 Prometheus 需要手动映射字段
Go 的 sql.DBStats 不是标准 metrics 类型，Prometheus client-go 不认它。必须自己写一层转换逻辑，把每个字段变成 GaugeVec 或 CounterVec 的样本值。
立即学习“go语言免费学习笔记（深入）”；
容易踩的坑是把 WaitCount 当成瞬时值去设 Gauge——它其实是累计值，该用 Counter；而 OpenConnections 是瞬时状态，才适合 Gauge。
- 推荐用
prometheus.NewGaugeVec管理OpenConnections、Idle、InUse - 用
prometheus.NewCounterVec管理WaitCount、MaxIdleClosed、MaxLifetimeClosed - 别漏掉 label：至少加一个
dblabel 区分不同数据源，比如db="user_db" - 每次采集都应调用
stats := db.Stats()再更新指标，不要复用旧 stats
go
// 示例：更新 OpenConnections 指标
dbConnGauge.WithLabelValues("user_db").Set(float64(stats.OpenConnections))
为什么 SetMaxOpenConns 和 SetMaxIdleConns 要早于第一次查询
这两个配置必须在第一次调用 db.Query 或 db.Exec 之前设置，否则会被忽略。原因是 *sql.DB 内部的连接池在首次执行时懒初始化，之后再改配置就只影响后续新建连接，无法回收已有连接或调整已建连接池大小。
- 典型错误：先
db.Query(...)，再db.SetMaxOpenConns(10)—— 此时上限仍是默认的 0（无限制） - 正确顺序：创建
*sql.DB→ 立即调用SetMaxOpenConns/SetMaxIdleConns/SetConnMaxLifetime→ 再开始业务查询 -
SetMaxIdleConns如果设得比SetMaxOpenConns大，实际生效的是后者；Go 会自动截断 - PostgreSQL 用户注意：
pgx驱动有自己的连接池实现，*sql.DB的 Stats 对它部分字段可能不准（如MaxIdleClosed）
连接池指标本身不报警，也不自愈；它只是把“连接正在变少/变多/卡住”这件事翻译成数字。真正关键的是你什么时候去看、跟什么基线比、以及看到异常后是否立刻能关联到某次发布或某类 SQL。
