数据库连接池枯竭的根本原因是连接被长期占用无法释放，而非单纯连接数设置过小；常见场景包括事务未提交或回滚、慢查询、panic未recover、空闲连接配置不当等，必须协同配置MaxOpenConns、MaxIdleConns和ConnMaxLifetime等参数，并通过pprof与日志验证泄漏。
数据库连接池枯竭不是“会不会发生”的问题，而是“什么时候发生”的问题——只要并发请求量超过 db.MaxOpenConns 且持续时间够长，就必然触发 driver: max connections exceeded 错误。
为什么连接池会枯竭？
根本原因不是连接数设得太小，而是连接被长期占用、无法释放回池。常见场景包括：
- 事务未显式
Commit()或Rollback()，导致连接卡在事务中 - 查询未设置超时，慢 SQL 持有连接长达数秒甚至更久
- 中间件或 handler 中 panic 未 recover，连接未被归还（Gin 默认不自动 rollback）
-
db.SetMaxIdleConns(0)或设得过低，空闲连接被频繁销毁重建
关键参数必须配对设置
只调 SetMaxOpenConns 是无效的。三个参数必须协同：
-
db.SetMaxOpenConns(100)：控制最大并发使用数，建议设为数据库服务端max_connections的 70%~80% -
db.SetMaxIdleConns(20)：保持常驻空闲连接，避免高频建连开销；值太小（如 0）会导致每次请求都新建连接 -
db.SetConnMaxLifetime(30 * time.Minute)：强制刷新老化连接，防止 TCP keepalive 失效后连接僵死
注意：SetConnMaxIdleTime（Go 1.15+）也应启用，例如设为 5 * time.Minute，避免空闲太久的连接被 DB 主动断开后 Gin 仍尝试复用。
事务必须用 defer 显式释放
Gin 不会自动管理事务生命周期。以下写法极易导致连接泄漏：
tx := db.Begin()
// ... 业务逻辑
if err != nil {
tx.Rollback() // ❌ 可能跳过
return
}
tx.Commit() // ❌ panic 时不会执行
正确做法是：
tx := db.Begin()
defer func() {
if r := recover(); r != nil {
tx.Rollback()
}
}()
if err := tx.Commit(); err != nil {
tx.Rollback()
}
更推荐封装成带 defer 的模板函数，或直接使用 db.Transaction(func(tx *gorm.DB) error { ... })（GORM v2+），它内部已做 recover + rollback。
连接泄漏要靠 pprof + 日志双验证
仅看错误日志不够。真正确认是否泄漏，需两步验证：
- 启动时开启
net/http/pprof，访问/debug/pprof/goroutine?debug=2查看是否有大量database/sql.*阻塞 goroutine - 在连接获取处加日志：
log.Printf("acquire conn, open: %d, idle: %d", db.Stats().OpenConnections, db.Stats().IdleConnections)
如果 OpenConnections 持续逼近 MaxOpenConns 且 IdleConnections 长期为 0，基本可判定连接未归还。
连接池配置不是一次调优就能一劳永逸的事——它必须和实际 QPS、平均响应时间、DB 端限制联动调整，且每次上线前都该用压测工具（如 wrk）跑满 5 分钟以上，观察 db.Stats() 输出变化。
