gin 依赖 database/sql 连接池，调优关键在于 *sql.db 配置；setmaxidleconns 必须 ≤ setmaxopenconns，否则被截断，设为 0 会导致每次请求新建连接；setconnmaxlifetime 推荐 30–60 分钟，setconnmaxidletime 推荐 5–15 分钟且须更短；通过 db.stats() 监控 waitcount、idle 和 openconnections 判断配置合理性。
Gin 本身不提供 SQL 连接池，它依赖 database/sql 的底层连接池机制。调优的关键不是“Gin 的连接池”，而是你用 sql.Open 创建的 *sql.DB 实例的配置。
为什么设置 SetMaxIdleConns 和 SetMaxOpenConns 后仍超时？
常见错误是只设了 SetMaxOpenConns，却忽略 SetMaxIdleConns 或设得过小（比如设成 0 或 1）。这会导致：空闲连接被快速回收，新请求来临时不得不新建连接；而新建连接耗时 + 网络延迟，容易触发 context deadline exceeded。
-
SetMaxIdleConns必须 ≤SetMaxOpenConns，否则会被静默截断为后者值 - 若
SetMaxIdleConns= 0，所有空闲连接立即关闭，等同于每次请求都新建连接 - MySQL 默认最大连接数通常是 151，
SetMaxOpenConns不宜设成 200 —— 会直接被数据库拒绝
SetConnMaxLifetime 和 SetConnMaxIdleTime 怎么配？
这两个参数控制连接“寿命”，直接影响连接复用率和 stale connection 错误（如 invalid connection）。
-
SetConnMaxLifetime：连接从创建起最多存活多久（推荐 30–60 分钟）。太短 → 频繁重建；太长 → 可能遇上数据库侧连接中断未感知 -
SetConnMaxIdleTime（Go 1.15+）：空闲连接在池中最多待多久（推荐 5–15 分钟）。比SetConnMaxLifetime短，避免空闲连接先于活跃连接失效 - 两者都设为 0 表示不限制，但生产环境不建议 —— 容易积累 stale 连接
如何验证连接池实际行为？
光看代码配置没用，得看运行时真实状态。在关键 handler 或定时任务里打印：
dbStats := db.DB().Stats()
log.Printf("open: %d, idle: %d, waitCount: %d, waitDuration: %v",
dbStats.OpenConnections,
dbStats.Idle,
dbStats.WaitCount,
dbStats.WaitDuration)
重点关注：
-
WaitCount持续增长 → 连接不够用，需调高SetMaxOpenConns -
Idle常年接近 0 →SetMaxIdleConns太小或SetConnMaxIdleTime太短 -
OpenConnections长期顶到SetMaxOpenConns→ 要么压测不足，要么业务逻辑有连接泄漏（defer db.Close()？没 defer rows.Close()？）
真正难的是平衡：设太高，压垮数据库；设太低，应用卡在等待连接。没有通用值，必须结合你的 DB 规格、QPS 和平均查询耗时去试 —— 尤其注意高峰期的 WaitDuration 是否突增。
