可通过调用 db.Stats() 获取 sql.DBStats 实时状态，包含 OpenConnections、IdleConnections、WaitCount 等原子安全字段；注意 WaitCount 是累计值，瞬时拥塞需判断 OpenConnections == MaxOpenConnections && IdleConnections == 0。
Go 的 database/sql 自带连接池，但默认不暴露实时监控指标——想看当前用了多少连接、空闲几个、有没有堆积等待，得靠手动挖接口 + 定期采样。
如何获取 *sql.DB 的实时连接池状态
*sql.DB 提供了 Stats() 方法，返回 sql.DBStats 结构体，里面包含连接数、空闲数、等待数等关键字段。它不是快照式统计，而是原子读取，线程安全。
-
MaxOpenConnections：最大允许打开的连接数（需提前调用SetMaxOpenConns()设置） -
OpenConnections：当前已建立（含正在用和空闲）的总连接数 -
IdleConnections：当前空闲在池中的连接数 -
WaitCount：累计有多少次请求因池满而阻塞等待（注意：是累计值，不是当前等待数） -
WaitDuration：这些等待总共耗时多久（也是累计）
示例：
stats := db.Stats()
fmt.Printf("open=%d idle=%d waitCount=%d\n",
stats.OpenConnections,
stats.IdleConnections,
stats.WaitCount)
为什么 Stats().WaitCount 不等于当前排队请求数
WaitCount 是自程序启动以来所有发生过的等待次数总和，无法反映“此刻是否卡住”。真正判断瞬时拥塞，得结合 OpenConnections == MaxOpenConnections 且 IdleConnections == 0 —— 这说明池已满、无空闲、新请求必等。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 只看
WaitCount上升快，可能是短时突发流量，未必代表持续瓶颈 - 若
WaitCount稳定增长但WaitDuration没明显变长，说明等待时间短，池响应尚可 - 真正危险信号是：长期
OpenConnections == MaxOpenConnections且IdleConnections常为 0
如何安全地定期采集并上报连接池指标
不能在 HTTP handler 或业务逻辑里频繁调用 db.Stats() 并打日志——它虽轻量，但高频采集+字符串拼接会带来 GC 和锁开销。推荐用独立 goroutine 拉取 + 聚合后上报。
- 采集间隔建议 ≥ 5 秒；太密无意义，还可能干扰性能观测
- 避免直接打印完整
sql.DBStats，只提取关心字段，转成 Prometheus 格式或 JSON 发给监控系统 - 如果用 Prometheus，可用
prometheus.NewGaugeVec按 DB 实例名打标，例如：db_conn_open{instance="user_db"} - 务必检查
db是否为非 nil，尤其在服务刚启动、DB 初始化未完成时调用Stats()会 panic
常见误配导致监控“失真”的情况
很多问题根本不是监控没做对，而是连接池本身配置不合理，让监控数据失去参考价值。
-
SetMaxOpenConns(0)：0 表示不限制，此时OpenConnections可能暴涨，WaitCount永远为 0——监控看起来健康，实际可能拖垮数据库 -
SetMaxIdleConns(n)设得太小（比如 1），空闲连接很快被回收，每次新请求都新建连接，IdleConnections长期为 0，但OpenConnections波动剧烈 - 忘记调用
SetConnMaxLifetime，连接长期复用导致数据库端连接老化断连，错误日志里出现driver: bad connection，而Stats()完全不体现这类失败
监控只是镜子，照出的是配置和使用方式。连池参数没对齐业务并发模型，再准的指标也救不了慢查询和连接泄漏。
