瓶颈不在gin本身，而在sql.db连接池配置不当和业务层未复用连接上下文；90%的“连接超时”“too many connections”源于setmaxopenconns与数据库max_connections不匹配、setmaxidleconns未合理设置或缺失setconnmaxlifetime导致连接老化堆积。
直接结论：瓶颈不在 Gin 本身，而在 sql.DB 连接池配置不当 + 业务层未复用连接上下文。 多数“连接超时”“too many connections”报错，90% 都是 SetMaxOpenConns 和 SetMaxIdleConns 没对齐数据库服务端限制，或没配 SetConnMaxLifetime 导致连接老化堆积。
为什么 db.SetMaxOpenConns(100) 反而让服务更慢？
这个值不是越大越好。它代表应用侧允许同时打开的**最大连接数**，但若超过 MySQL 的 max_connections（默认通常 151），就会触发拒绝连接；即使没超，也可能因连接长期不释放，挤占其他服务或后台任务的连接资源。
- 查 MySQL 实际上限：
SHOW VARIABLES LIKE 'max_connections'; - 生产建议值 =
MySQL max_connections × 0.6 ~ 0.8，预留空间给监控、备份、运维工具 - 如果用了读写分离或分库，每个
*sql.DB实例都要单独配，不能共用一套数值 - 设得过高还会掩盖真实问题——比如某接口没关
rows或没用defer tx.Rollback()，导致连接泄漏，但错误日志只显示“timeout”，不提示泄漏点
SetMaxIdleConns 和 SetConnMaxLifetime 必须成对出现
只设空闲连接数却不设生命周期，等于在养一堆“僵尸连接”：它们长期空闲、TCP 状态可能已断开，但池子还留着，下次借出时才发现不可用，触发重连+重试，延迟飙升。
-
db.SetMaxIdleConns(10)：建议设为平均并发请求数的 20–30%，不是拍脑袋填 50 -
db.SetConnMaxLifetime(30 * time.Minute)：强制连接在池中存活不超过 30 分钟，逼它定期刷新，避免 stale connection -
db.SetConnMaxIdleTime(5 * time.Minute)（Go 1.15+）：比老版SetMaxIdleConns更精准，空闲超时后立即回收，推荐优先用这个
Gin 中间件里别直接调 db.Query，用 context.Context 带超时
没带 context 的 DB 调用，一旦数据库卡住，Gin 请求协程就卡死，既不返回也不释放连接，快速拖垮整个连接池。
- 正确写法：
rows, err := db.QueryContext(c.Request.Context(), "SELECT ...") - 全局加超时中间件：
r.Use(func(c *gin.Context) { c.Request = c.Request.WithContext(context.WithTimeout(c.Request.Context(), 3*time.Second)) }) - 注意：MySQL 的
readTimeoutDSN 参数（如readTimeout=3s）只是 TCP 层超时，无法中断正在执行的慢查询；必须靠QueryContext+ cancel signal 才能真正中断
最易被忽略的一点：连接池参数改了，但没 reload 应用。Gin 启动时初始化一次 *sql.DB，后续修改 SetXXX 方法不会自动生效——必须在 sql.Open 之后、首次使用前完成所有 Set* 调用，且不能在 handler 里反复调用这些 setter。
