Go语言微服务开发中解决连接池超限的问题

服务日志里频繁出现 sql: connection limit exceeded 或 dial tcp: lookup xxx: no such host，Prometheus 监控显示 sql_open_connections 持续打满、sql_idle_connections 接近零——这不是数据库扛不住，而是 Go 应用自己把连接池“撑爆”了。

连接池超限的典型表现和根本原因

根本原因其实很简单，无非两个方向：一是 SetMaxOpenConns 设得比数据库的 max_connections 还高，二是代码里漏掉了 rows.Close() 或 tx.Commit()/Rollback()，连接干脆就不回池子里了。

• MySQL 默认 max_connections=151，不少 Go 项目直接写 db.SetMaxOpenConns(0)（无限制）或者 200，一上线就触发数据库拒绝新连接
• database/sql 不会自动帮你关 *sql.Rows，必须显式调用 rows.Close()；事务也得配好 Commit()/Rollback()，否则连接就卡在“in use”状态
• 连接泄漏常常藏在 defer 里：比如 defer rows.Close() 写在循环体外，或者错误分支没覆盖到

三个关键参数怎么设才不踩坑

别照抄网上给的示例值。每个参数都得跟你自己的部署环境、数据库配置和 QPS 匹配上。

• SetMaxOpenConns(n)：必须小于等于数据库 max_connections 乘以（Pod 数量除以副本数）。举个例子，MySQL 的 max_connections=200，K8s 里部署了 3 个 Pod，那么单个 Pod 最多设 66，留点余量的话建议 50
• SetMaxIdleConns(m)：一般设为 SetMaxOpenConns 的 1/3 到 1/2。设太小（比如默认的 2）会导致高峰期频繁新建连接；设太大（等于 MaxOpen）又白白浪费空闲连接
• SetConnMaxLifetime(d)：设得略小于数据库的 wait_timeout（MySQL 默认是 8 小时）。推荐 1h 到 3h，避免连接被数据库主动 kill 后 Go 端还在尝试复用

这里有个错误示范：db.SetMaxOpenConns(100); db.SetMaxIdleConns(100)——Idle 和 Open 设成一样大，等于放弃了连接复用策略，所有连接都长期驻留着。

如何快速定位连接泄漏

光靠 review 代码很难找到所有漏关的地方。得用数据说话。

• 加一行监控：初始化 *sql.DB 之后，定期打点 db.Stats()，把 OpenConnections、IdleConnections、InUse 三个指标暴露到 Prometheus
• 压测时观察曲线：如果 InUse 持续上涨不回落，基本就能确认泄漏；再结合 pprof heap 查 *sql.conn 对象数量是不是跟着请求线性增长
• 加日志钩子：重写 driver.Conn 的 Close() 方法（需要包装底层 driver），记录每次 Close 调用的来源，就能找到没释放的 goroutine

注意：db.Close() 是关掉整个连接池，不是释放单个连接，千万别在 handler 里调它。

gRPC 或 HTTP 客户端连接池也要同样对待

很多人只盯着数据库连接池调，却忘了下游调用的连接池。gRPC 的 grpc.Dial、HTTP 的 http.DefaultClient 都有内置连接池，不调优照样超限。

• gRPC：用 grpc.WithTransportCredentials 配合 grpc.WithKeepaliveParams 控制长连接复用，再用 grpc.WithBlock() 避免 Dial 阻塞；连接数上限靠 grpc.WithConnectParams 中的 MinConnectTimeout 和重试逻辑间接控制
• HTTP：替换掉 http.DefaultClient，自定义 http.Transport，重点设置 MaxIdleConns、MaxIdleConnsPerHost、IdleConnTimeout——这三个不设的话，默认值是 100、2、30s，很容易就打满文件描述符
• 共通陷阱：多个微服务共用一个全局 client 实例没问题，但千万别在 handler 里 new 一堆 client，每个都带着独立的连接池

最容易被忽略的是：数据库池和 HTTP/gRPC 池的资源消耗叠加后，可能先耗尽的是系统级的 fd（ulimit -n），而不是某个具体池的上限。