连接池耗尽时表现为context deadline exceeded等超时错误，而非连接拒绝；根本原因多为事务未释放导致连接泄漏，需通过db.stats()监控并确保每条sql.tx都闭环调用commit/rollback。
go数据库连接池耗尽的典型错误表现
连接池耗尽时，database/sql 不会立刻 panic，而是让后续 Query、Exec 或 Begin 调用在 sql.DB 内部阻塞，直到超时或上下文取消——你看到的往往是 context deadline exceeded，而不是 “connection refused” 或 “too many connections”。更隐蔽的是，某些请求卡住几秒后才失败，日志里却找不到 DB 层报错，容易误判为业务逻辑慢。
- 常见现象：
sql: connection pool exhausted（仅当启用了SetMaxOpenConns且设得过小 + 长事务未释放） - 真实瓶颈常在：事务没
Commit/Rollback、defer 忘写、panic 后未 recover 导致连接泄漏 - 注意：
sql.ErrNoRows是正常错误，和连接池无关；但反复出现它+高延迟，可能说明查询没加 limit 或索引缺失，间接拖长连接占用时间
如何正确配置 sql.DB 的连接池参数
sql.DB 本身不是连接，而是一个连接池管理器。它的三个关键参数相互制约，不能只调大 MaxOpenConns 就完事。
-
SetMaxOpenConns(n)：最大打开连接数。设为 0 表示无限制（危险！），生产环境建议 ≤ 数据库侧max_connections的 70%；值太小会导致排队，太大可能压垮 DB -
SetMaxIdleConns(n)：空闲连接上限。默认 2，建议设为Min(MaxOpenConns, 20)左右，避免频繁建连/销毁开销 -
SetConnMaxLifetime(d)：连接最长存活时间。必须设（如1h），否则连接可能因 DB 侧 timeout 被静默断开，下次复用时报i/o timeout
示例：
db, _ := sql.Open("pgx", dsn) db.SetMaxOpenConns(25) db.SetMaxIdleConns(20) db.SetConnMaxLifetime(1 * time.Hour) db.SetConnMaxIdleTime(30 * time.Minute) // Go 1.15+ 才有，控制空闲连接回收监控连接池状态的最简可行方法
别等报警才看。golang 的 sql.DB 提供了 Stats() 方法，返回 sql.DBStats，里面全是真实运行时指标，比任何第三方 exporter 都准。
立即学习“go语言免费学习笔记（深入）”；
- 关键字段：
OpenConnections（当前打开数）、IdleConnections（当前空闲数）、WaitCount（排队等待连接总次数）、WaitDuration（所有等待总耗时） - 高频检查点：http 健康检查接口（如
/healthz）中直接返回db.Stats()，不用额外埋点 - 警惕信号：
WaitCount > 0且持续增长 → 池子不够用；OpenConnections == MaxOpenConns且IdleConnections == 0→ 连接几乎全被占满，再叠加长事务就危险
简单打印示例：
stats := db.Stats() log.printf("DB stats: open=%d idle=%d wait=%d waitDur=%v", stats.OpenConnections, stats.IdleConnections, stats.WaitCount, stats.WaitDuration)事务中忘记释放连接的硬核排查法
90% 的连接泄漏来自事务。Go 的 sql.Tx 不是自动回收资源的句柄，它持有一个独占连接，直到你显式调用 Commit 或 Rollback。
- 常见错误模式：defer
tx.Rollback()但没判断tx == nil；或者 panic 后 defer 没触发（比如在 defer 外层又 panic） - 安全写法：用
if tx != nil { tx.Rollback() }包裹 defer；或统一用函数封装事务逻辑（类似db.Transaction(func(tx *sql.Tx) Error { ... })） - 快速验证：在事务开始前打日志
log.Printf("tx start, conn id: %p", tx)，结束时再打一次，看是否成对出现；不推荐用runtime.Stack查，太重
真正难缠的是嵌套事务或 ORM（如 GORM）隐式开启的事务——它们可能绕过你的手动控制，此时必须查清其事务生命周期文档，而不是凭感觉加 defer。
连接池问题从来不是“配多大”的问题，而是“谁拿了不还”和“还了能不能再用”的问题。监控数字只是表象，代码里每一条 tx. 开头的调用，都得能闭环到一次 Commit 或 Rollback。