为什么你的连接池迟早会把你坑死？
你以为设个 MaxOpenConns 就完事了？天真。
先讲个真实的故事
我接手过一个接口，平均响应时间 80ms，看起来很健康。但某天突然开始，每隔半小时左右，就会有一小批请求超时。研发查了半天，说是"网络抖动"。后来我介入，一看日志，连接池在作妖。
问题很简单：线上跑了 3 个月，连接池一个参数都没改过。Dev 环境 10 个并发，线上 1000 并发，连接池还是 MaxOpenConns = 100。不是网络抖动，是连接不够用了。
这是一个极端例子，但连接池的坑，远比你想象的深。
一、MaxOpenConns 和 MaxIdleConns：大多数人的理解是错的
最常见的配置：
db.SetMaxOpenConns(100)
db.SetMaxIdleConns(100) // 错误！把 MaxIdleConns 设成和 MaxOpenConns 一样，看起来很合理——保持连接备用嘛。但这里面有个反直觉的事实：
MaxIdleConns 过大是性能杀手。
每个空闲连接都要消耗服务端资源，而且 Go 的 database/sql 包在连接复用时，会先检查连接是否可用。如果连接被服务端 kill 了，Go 会重试一次，失败后才报错。这意味着空闲连接越多，你遇到 "bad connection" 的概率越高。
正确的做法是：MaxIdleConns < MaxOpenConns，通常设为预期并发峰值的 1/3 到 1/2 就够了。
db.SetMaxOpenConns(100)
db.SetMaxIdleConns(30) // 合理值二、ConnMaxLifetime：这个参数不设，迟早出事
这是最容易忽略的参数，也是最危险的一个。
MySQL 默认的 wait_timeout 是 8 小时，PostgreSQL 是 30 分钟。而 Go 的 database/sql 默认 ConnMaxLifetime 是 0，意味着连接永不过期。
问题来了：
- 服务端主动关闭了空闲连接（网络闪断、负载均衡重置等）
- Go 不知道连接已死，还以为它活着
- 下一个请求拿到这个"僵尸连接" → bad connection → 重试 → 用户看到超时
我见过最离谱的 case：应用连的是 RDS，每次网络抖动（比如运营商割接），就会触发一波 bad connection 错误。查了半天，最后加了一行：
db.SetConnMaxLifetime(5 * time.Minute) // 小于服务端的 wait_timeout好了，世界安静了。
经验法则：ConnMaxLifetime 要小于数据库服务端的空闲超时时间，通常设为 3-5 分钟。
三、ConnMaxIdleTime：很多人不知道有这个参数
这是 Go 1.15 引入的参数，比 ConnMaxLifetime 更精细——只针对空闲连接。
假设你设置了 MaxIdleConns = 30，但实际并发只需要 5。那么剩下的 25 个连接就空着。ConnMaxIdleTime 做的就是：把这些多余的空闲连接也定期清理掉。
db.SetConnMaxIdleTime(1 * time.Minute)这个参数解决的是"连接池膨胀"的问题——长期低负载时，连接池依然保持大量连接，浪费资源。
ConnMaxLifetime 和 ConnMaxIdleTime 的关系：
- ConnMaxLifetime：所有连接的寿命上限
- ConnMaxIdleTime：空闲连接的寿命上限（更积极清理）
两个都设，连接池会更健壮。
四、健康检查查询：你以为在保护自己，可能在伤害自己
很多人会在连接池上配置 ConnValidateFunc 或者用 ProxySQL 等中间件做连接检测。看起来很安全，但...
健康检查有代价：
- 每次拿连接都要多一次 ping（如果用 CHECK 类型的健康检查）
- 检测频率太高 = 额外负载（很多健康检查间隔设成 5-10 秒，其实 30 秒够了）
- 检测本身会创建新连接，在高并发短连接场景下，健康检查连接可能反而成为瓶颈
更好的思路是：让连接死在业务里，而不是死在检测里。
Go 的 database/sql 在执行查询时，如果底层连接报错，会自动重试一次（仅限一次，且仅限 idempotent 的查询）。与其花资源做健康检查，不如依赖这个重试机制，同时把 ConnMaxLifetime 设短，让连接自然更替。
五、DNS TTL 缓存：连接池和微服务的隐形杀手
这是一个很少有人提，但影响巨大的问题。
假设你的服务连接 mysql.prod.svc.cluster.local，DNS TTL 是 30 秒。某天数据库发生 failover，IP 变了。但你的连接池里有 100 个连接，全是连到旧 IP 的。直到这些连接全部超时或被清理，你才能拿到新 IP 的连接。
在高可用切换场景下，这可能造成几分钟的服务中断。
解法：
- DNS TTL 设短一点（5-10 秒，不要设 0，会带来其他问题）
- 连接串通时带上域名，而不是 IP（有些中间件支持）
- 定期清理连接池（ConnMaxLifetime 就是干这个的，所以它很重要）
六、实战配置模板
给你一个我在线上用过的配置，直接抄：
db, err := sql.Open("mysql", "user:password@tcp(host:3306)/dbname?parseTime=true")
if err != nil {
log.Fatal(err)
}
// 关键参数
db.SetMaxOpenConns(100) // 最大并发连接数
db.SetMaxIdleConns(30) // 空闲连接池大小（< MaxOpenConns）
db.SetConnMaxLifetime(5 * time.Minute) // 连接最大寿命
db.SetConnMaxIdleTime(1 * time.Minute) // 空闲连接最大空闲时间然后配合监控：
func RecordDBMetrics(db *sql.DB) {
go func() {
for {
stats := db.Stats()
metricOpenConnections.Set(float64(stats.OpenConnections))
metricInUseConnections.Set(float64(stats.InUse))
metricIdleConnections.Set(float64(stats.Idle))
time.Sleep(15 * time.Second)
}
}()
}如果 OpenConnections == MaxOpenConns 持续超过 1 分钟，告警。
如果 Idle == MaxIdleConns 持续，告警——说明并发在下降，连接池设大了。
七、最重要的一句话
连接池调优没有银弹，参数要跟着流量特征走。
连接池太小 → 并发受限 → QPS 上不去
连接池太大 → 资源浪费 → 服务端 OOM
MaxLifetime 太长 → 僵尸连接 → 偶发超时
MaxLifetime 太短 → 连接频繁重建 → CPU 飙升
你需要的不是背参数，是理解原理，然后上监控，让数据告诉你该怎么调。
最后送你一句话：连接池就像内裤，不需要多华丽，但一定要合身，而且要定期检查有没有破洞。
写完收工。🦐
