做后端开发这么多年，数据库连接这事儿，说大不大说小不小。但凡在生产环境踩过连接泄漏的坑，你就能深刻理解为什么连接池是必修课。
故事的起因
刚工作那会儿，我天真地以为数据库连接就是“用完关掉”这么简单。于是我的代码里到处都是conn.Close()，自以为写得挺优雅。直到某天服务器报警，说数据库连接数爆了——那一刻我才意识到，too young too simple sometimes naive。
问题出在哪？出在我那些“用完就关”的代码里，有些分支压根没走到Close()，异常一来连接就泄漏了。生产环境跑了几个小时，连接数从几十直接飙到几千，数据库直接躺平。
连接池是什么
连接池的核心思想很简单：不要随用随开，而是提前建立好一批连接，用完放回去而不是真的关闭。下次要用，从池子里拿一个，用完还回去。
这么搞的好处：
- 避免了频繁建连的 overhead，特别是对短连接场景简直是救星
- 限制了最大连接数，不会把数据库打爆
- 异常情况下的保护机制，比你手动Close靠谱多了
手动管理连接的三大作死行为
我见过太多人（包括以前的我）踩过这些坑：
作死行为一：把连接当局部变量
func handler(w http.ResponseWriter, r *http.Request) {
db, _ := sql.Open("mysql", "...")
// 这个db用完没关闭，下次请求又新建一个
row := db.QueryRow("SELECT * FROM user WHERE id = ?", 1)
// 没有错误处理，没有关闭，直接埋雷
}作死行为二：异常路径忘记释放连接
func someQuery() error {
conn, err := getConn()
if err != nil {
return err
}
// 很多行代码...
if someCondition {
return errors.New("early return!") // 这里直接返回了，conn没人管
}
conn.Close()
return nil
}作死行为三：不设置连接超时和读写超时
数据库挂了或者网络抖动，你的连接就卡在那儿等，等到天荒地老。不设置超时，连接池就失去了保护意义。
Go语言里连接池的正确打开方式
Go的database/sql包自带连接池，用起来其实很省心，但很多人不知道它的正确配置方式。
db, err := sql.Open("mysql", "user:password@tcp(host:3306)/db?parseTime=true")
if err != nil {
log.Fatal(err)
}
// 设置最大打开连接数，别让数据库压力太大
db.SetMaxOpenConns(25)
// 设置最大空闲连接数，不是越大越好
db.SetMaxIdleConns(10)
// 设置连接的最大生命周期，别让老连接占着不放
db.SetConnMaxLifetime(5 * time.Minute)
// 设置空闲连接的最大存活时间
db.SetConnMaxIdleTime(1 * time.Minute)这里有个坑：SetMaxIdleConns不是越大越好。很多人以为多开点空闲连接能提高性能，结果反而浪费内存。最佳实践是根据你的QPS和数据库的处理能力来调，一般来说MaxOpenConns设置成CPU核心数的2-4倍比较合理。
连接泄漏的自检方法
怎么知道自己的代码有没有泄漏？两个办法：
方法一：监控连接池指标
// 定期打印连接池状态
fmt.Printf("OpenConnections: %d\n", db.Stats().OpenConnections)
fmt.Printf("InUse: %d\n", db.Stats().InUse)
fmt.Printf("Idle: %d\n", db.Stats().Idle)
fmt.Printf("WaitCount: %d\n", db.Stats().WaitCount)
fmt.Printf("MaxIdleClosed: %d\n", db.Stats().MaxIdleClosed)
fmt.Printf("MaxLifetimeClosed: %d\n", db.Stats().MaxLifetimeClosed)如果InUse持续增长，而Idle永远是0，那基本可以确诊泄漏了。
方法二：打日志
在获取连接和释放连接的地方打详细日志，加上调用栈信息。虽然有点土，但定位问题非常有效。
连接池调优的实战经验
说几个我实际调优过的案例：
案例一：高频短查询场景
有个接口是获取用户信息的，QPS特别高，用的PostgreSQL。每次查询都是新建连接，连接开销比查询本身还大。解决方案：调高MaxIdleConns到50-100，保证有足够的空闲连接复用。同时把ConnMaxIdleTime设短一点，比如30秒，避免空闲连接失效。
案例二：批量导入场景
批量导入数据时，需要短时间建立大量连接。这时候如果连接池太小，就会排队等待，性能反而差。解决方案：临时调大MaxOpenConns，导入完成后再调回来。代码里可以加个开关。
案例三：数据库升级后的连接池配置
数据库从5.7升级到8.0后，连接池突然开始报连接超时。排查了半天，发现是8.0的默认等待超时从8小时改成了10秒。原来空闲连接“假装还活着”，其实已经无效了。解决方案：把ConnMaxIdleTime设得比数据库超时时间短，确保连接健康。
别把连接池当银弹
连接池不是万能的，它只能缓解问题，不能解决所有性能问题。如果你的查询本身就慢（没加索引、SQL写得太烂），再怎么调连接池也没用。
真正的高性能，靠的是：
- 合理的索引
- 优化的SQL
- 恰当的缓存策略
- 以及——一个配置合理的连接池
连接池只是基础设施，不是性能优化的终点。把它配置好，是为了让你少踩坑，把精力放在真正重要的事情上。
总结一下
手动管理数据库连接，是新人最容易犯的错误之一。别觉得自己比连接池更聪明，库里的实现都是踩过无数坑才写出来的。用好连接池的配置项，理解每个参数的意义，比自己造轮子强一百倍。
记住：连接泄漏不是小事，它可能在你最忙的时候给你致命一击。提前做好监控和配置，比出事之后再救火，划算多了。
