Go 的 database/sql 自带健壮连接池，无需手动封装；应合理设置 SetMaxOpenConns 和 SetMaxIdleConns，监控 db.Stats()，事务中统一使用 tx 对象并配超时，同时配对使用 db.Ping() 与 SetConnMaxLifetime。
Go 的 database/sql 本身已是连接池，所谓“封装”多数是画蛇添足；真正要做的，是配对调参、盯住 db.Stats()、堵住泄漏点。
为什么自己封装 sql.DB 连接池大概率出错
很多人看到“连接池”就下意识想写个 sync.Pool 包一层 *sql.Conn 或用 map 存连接——这在 database/sql 场景下完全没必要，且危险：
-
sql.DB内置连接池已足够健壮，它管理的是底层 driver.Conn 的生命周期，不是简单对象复用 - 手动包装
*sql.Conn会绕过sql.DB的空闲队列、超时回收、健康检查逻辑，导致 stale 连接复用失败或 panic - 并发调用
db.Query/db.Exec时，sql.DB自动从池中取可用连接；你封装的“池”若没做 Get/Put 幂等性，网络错误重试可能把同一连接 Put 两次，引发 double-close - 事务（
tx）必须独占连接，你的封装无法感知 tx 生命周期，极易造成连接泄漏或阻塞
SetMaxOpenConns 和 SetMaxIdleConns 怎么设才不拖慢 P99
这两个值不是凭经验拍脑袋，而是要对齐数据库资源上限和业务真实负载：
-
SetMaxOpenConns必须显式设置：默认0（无限制）等于放任连接数爆炸，MySQL 默认max_connections=151→ 建议设 ≤100 - 合理估算公式：
峰值 QPS × 平均查询耗时(秒) × 1.5，例如 QPS=200、平均耗时 60ms →200 × 0.06 × 1.5 = 18，再与 DB 上限取 min -
SetMaxIdleConns必须 ≤SetMaxOpenConns，否则 Go 1.12+ 直接 panic；生产常用SetMaxOpenConns的 1/2～2/3（如 Open=100 → Idle=50） - 设太高会压垮 DB：PostgreSQL 每个连接占一个 backend process，空闲连接堆积导致上下文切换开销飙升、P99 延迟毛刺
不监控 db.Stats() 就等于盲调参数
只改参数不看指标，和蒙眼开车没区别。重点关注这三个字段的**趋势变化**：
立即学习“go语言免费学习笔记（深入）”；
-
WaitCount持续上升 → 连接不够用，优先调高SetMaxOpenConns，而不是加机器 -
InUse长期等于MaxOpenConns→ 连接被借出后没归还，查rows.Close()是否漏写、事务是否未Commit/Rollback -
MaxIdleClosed频繁增长 → 空闲连接回收太激进，适当提高SetMaxIdleConns或延长SetConnMaxIdleTime - 每分钟打一次
db.Stats()推送到 Prometheus，比日志更早发现连接池“假忙”（大量idle in transaction却无实际查询）
事务里混用 db.Query 和 tx.Query 是隐形炸弹
事务内调用 db.Query 不仅不参与事务，还会额外占用一个连接，极易引发连接池饥饿：
-
tx.Query绑定专属连接，db.Query从全局池另取连接 → 同一事务里两个连接并行跑，数据不一致风险高 - 若事务卡在 HTTP 请求上，
tx连接长期 hold，db.Query又占一个，其他 goroutine 全在WaitCount里排队 - 所有 SQL 操作必须统一走
tx对象：tx.Query、tx.Exec，禁用任何db.Xxx - 开启事务必须带
context.WithTimeout，例如ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)，防止事务无限挂起
最常被忽略的其实是 db.Ping() 和 SetConnMaxLifetime 的协同：不 Ping()，服务启动成功但首次请求才暴露连通性问题；不设 SetConnMaxLifetime（略小于 DB 的 wait_timeout），中间件断连后复用就会报 "invalid connection" —— 这俩动作必须成对出现，缺一不可。
