每次HTTP请求开闭数据库连接：实际场景下是否存在问题咨询

我们团队在早期的电商项目里刚好遇到过一模一样的情况——当时数据层每次HTTP请求都新建、销毁数据库连接，高峰100QPS左右，先后用了MySQL和PostgreSQL，踩了不少实打实的坑：

• 接口响应性能暴跌
  每次连接都要走TCP三次握手、数据库身份验证、会话初始化（设置时区、字符集、隔离级别）这些流程，单连接建立耗时大概8-15ms。100QPS下，光是连接开销就占了接口总响应时间的30%-40%，原本20ms能搞定的接口，高峰时直接涨到50ms以上，用户明显感觉到页面加载变慢。

• 数据库连接数直接打满
  MySQL默认max_connections是151，PostgreSQL默认只有100。如果遇到慢查询、锁等待或者突发流量，连接释放不及时，瞬间就会触发Too many connections错误。我们曾因为一次索引失效导致慢查询，每个连接持有时间从20ms拉长到200ms，10分钟内就把MySQL连接数耗光，新请求全部报错，排查了好久才恢复。

• 数据库服务器负载飙升
  频繁创建、销毁连接会让数据库不断启停会话进程/线程，CPU和内存消耗剧增。我们监控到用这种方式时，MySQL的CPU使用率比后来用连接池时高了40%，PostgreSQL更是高了近50%，高峰时段服务器负载告警不断，不得不临时扩容数据库节点。

• 事务一致性无法保障
  有些业务逻辑需要跨多个操作保持事务（比如扣库存+生成订单），但每次开关连接意味着每个操作都是独立会话，根本没法用同一个事务。我们之前出过一次线上事故：库存扣减成功，但订单创建失败，因为两个操作不在同一个连接的事务里，最后只能靠定时任务做数据补偿，折腾了好几天。

• 隐性连接泄漏
  虽然代码里写了finally块关闭连接，但如果遇到未捕获的异常（比如第三方服务调用超时导致的RuntimeException），连接可能没被正确释放。我们曾排查过一次连接泄漏：某个支付回调接口的异常分支没处理，连接没关，高峰跑了3小时就把PostgreSQL连接数打满，导致整个订单系统瘫痪。

后来我们全量替换成连接池（MySQL用HikariCP，PostgreSQL用PgBouncer+HikariCP），设置了合理的最小/最大连接数、连接超时和回收机制，上面的问题全部解决，接口响应时间直接回到正常水平，数据库负载也降了下来。当然改造的时候因为很多组件依赖旧的连接逻辑，花了不少时间做兼容，但长远来看绝对是必须的优化。

内容的提问来源于stack exchange，提问作者Anton Komarov