前几天一个朋友跟我说，他们有个服务白天跑得好好的，一到晚上就各种超时报警，查了半天发现是定时任务大量读写数据库，把连接池打爆了。他很困惑：「我配的是默认配置啊，默认配置不应该就是最稳妥的吗？」

我当时差点把口中的小龙虾啤酒喷出来。

默认配置，是给Demo用的，不是给生产环境用的。这个认知差距，坑了至少80%的后端工程师。

你的连接池在假装工作

先说个冷知识：大多数主流语言的数据库连接池，默认max_connections通常是10-20。听起来不多？但问题是，当你的服务有100个并发请求同时进来，而数据库最多只能承受15个连接，剩下85个请求就开始排队。

排队的请求不会立即失败，它们会等。等多久？取决于你的超时配置。如果超时配置是30秒，那这85个请求会活活等30秒然后失败。这30秒里，用户看到的就是「请求转圈」。

更骚的操作来了——很多工程师看到超时报错，第一反应是「调大超时时间」。超时从30秒改成300秒。结果呢？请求没超时了，但所有请求都在等数据库连接，CPU空闲，内存稳定，但QPS断崖式下跌。用户不报超时了，开始报「服务好慢」。

这不是在解决问题，这是在掩盖问题。

连接池的三个死亡陷阱

陷阱一：连接泄漏

什么叫连接泄漏？你的代码向连接池要了一个连接，用完了，但是没有还回去。这个连接就「消失」了，池子里可用的连接越来越少，直到耗尽。

看这段代码：

func getUserById(id int) (*User, error) {
    conn, err := dbPool.GetConnection()
    if err != nil {
        return nil, err
    }
    // 假设这里有个条件判断
    if id < 0 {
        return nil, errors.New("invalid id")
    }
    // 问题来了：如果 id < 0，上面已经 return 了
    // conn 永远没有被释放！
    user := conn.QueryRow("SELECT * FROM users WHERE id = ?", id)
    return user, nil
}

这是一个极其简化但真实存在的泄漏场景。正确的写法应该是用 defer：

func getUserById(id int) (*User, error) {
    conn, err := dbPool.GetConnection()
    if err != nil {
        return nil, err
    }
    defer conn.Close() // 无论如何都会执行
    if id < 0 {
        return nil, errors.New("invalid id")
    }
    user := conn.QueryRow("SELECT * FROM users WHERE id = ?", id)
    return user, nil
}

但问题是，在某些语言里（比如老PHP时代），连接对象在函数结束时不一定自动归还。可能有人说Python的SQLAlchemy不是有session自动管理吗？是的，但如果你手动关闭了session或者在多线程环境下共享session，泄漏照来不误。

陷阱二：池子太小，并发打不进去

我见过最离谱的生产配置是这样的：服务跑了50个Golang协程，数据库连接池max是5。每个协程都在等连接，数据库CPU利用率只有5%，但P99延迟是500ms。

这不是数据库的问题，这是连接池配置和使用场景完全不匹配的问题。

计算连接池大小的公式有很多，比较经典的是：

连接数 = ((核心数 * 2) + 磁盘数)

但这是针对PostgreSQL这种用的是进程/线程模型的数据库。对于像MySQL这种用线程模型的，通常建议是：

连接池大小 = (核心数 * 线程池系数) + 备用

线程池系数一般取2到4。但说实话，没有什么公式能替代真实压测。正确的方法是：先设置一个合理初始值，然后压测，观察数据库连接数和响应时间的变化曲线，找到拐点。

陷阱三：池子太大，数据库扛不住

等等，刚才说太小会出问题，那大一点总没毛病吧？错，大了也会出问题。

假设你的MySQL的max_connections是200，你部署了4个服务实例，每个实例连接池大小设为100。看起来每个实例都「只用」了一半的连接容量。但问题在于——连接池说的是最大同时持有数，不是实际使用数。

当你的服务实例重启或者遇到流量高峰时，4个实例同时需要连接，200 + 100 + 100 + 100 + 100 = 500的连接需求，但MySQL只能承受200。MySQL会直接拒绝多余连接，你的服务会报「too many connections」。

所以连接池大小的上限，一定要是MySQL max_connections的70%以内（留30%给运维连接和备用）。如果有4个实例，那每个实例的max应该是200 * 0.7 / 4 ≈ 35，而不是100。

一个真实的惨案

说个我亲眼见过的生产事故。

某电商大促期间，团队提前扩容，加了3倍的机器，心想这下稳了。结果大促开始5分钟后，整个服务雪崩。

查日志发现，数据库连接数直接打满了，所有新请求都在等连接。更诡异的是，扩容前没事，扩容后反而出事了？

原因很简单：他们用的是Go语言，每个实例启动时会有一个「预热」阶段，批量查询数据填充缓存。扩容前只有1个实例在预热，扩容后4个实例同时预热，4倍的数据库查询同时打过来，数据库直接原地去世。

解决方案：给预热阶段加了并发控制，让所有实例不要同时预热，错开时间。同时调整了连接池的预获取策略。

实战配置建议

说一千道一万，给点实打实的配置建议：

• 初始连接数不要等于最大连接数。初始值可以设为最大值的30%-50%，让连接池「按需增长」，避免资源浪费。
• 连接最大生命周期（maxLifetime）一定要设。数据库连接是有状态的，PHP的long-lived连接可能因为服务端断开导致「空连接」。建议maxLifetime设2到4小时，并且小于数据库服务器的wait_timeout。
• 连接获取超时（connectionTimeout）要合理。太长会放大问题（比如请求堆积），太短会误杀正常请求。建议5到15秒，并且配合熔断机制使用。
• 最小空闲连接（minIdle）根据业务特性来。如果是高流量、延迟敏感的服务，可以保留一些预热连接，减少冷启动的开销。如果是低流量服务，设为0可以节省资源。

监控才是硬道理

最后，也是最重要的一点：监控你的连接池。

你需要知道：当前活跃连接数、空闲连接数、等待获取连接的请求数、连接获取失败的次数。这些指标能让你在用户报障之前就发现问题。

很多团队装了监控但从来没看过，直到线上炸了才想起来「咦我们好像有监控来着」。这是不对的。

连接池的监控应该是基础设施级别的，跟监控CPU、内存一样重要。一个健康的系统，连接池各项指标应该是稳定的。如果发现活跃连接数在持续增长，或者等待获取连接的请求数在增加，这就是预警信号——说明你的池子配置和实际使用不匹配了。

写在最后

连接池这玩意儿，看着简单，实际上是个深坑。默认配置救不了你，搜索引擎也救不了你，只有理解原理、监控指标、结合真实场景配置，才能让你的服务跑得稳。

下次再遇到超时问题，别急着调超时时间。先问问自己：连接池，你真的懂它吗？