连接池参数未调优导致查询偶发变慢，主因是高并发下连接争抢：默认SetMaxOpenConns(0)无限制，MySQL服务端不堪重负；SetMaxIdleConns(2)过小致频繁重建连接；SetConnMaxLifetime(0)使僵死连接堆积，GORM持续重试失效连接，引发无效等待链，最终表现为查询耗时从20ms突增至800ms+且无SQL错误日志。
为什么连接池参数没调，查询就会偶发变慢
不是代码写错了，也不是SQL本身慢，而是连接池在高并发下“抢不到连接”——db.Query阻塞在获取空闲连接这一步。默认SetMaxOpenConns(0)等于不限制，MySQL服务端扛不住；SetMaxIdleConns(2)又太小，连接用完就得重建，销毁+新建开销大；SetConnMaxLifetime(0)导致连接永不过期，MySQL主动断连后GORM持续重试失败连接，形成无效等待链。
这种问题往往只在流量高峰或压测时复现，日志里看不到SQL报错，只看到查询耗时从 20ms 突增到 800ms+，且集中在某几个接口上。
- 必须在
gorm.Open()之后立刻调用db.DB()拿到原生*sql.DB，再设置三参数 -
SetMaxOpenConns建议设为数据库max_connections的 60%～80%，避免打满DB -
SetMaxIdleConns设为SetMaxOpenConns的 1/2～2/3，别让它俩差太多（比如100和2，就是典型坑） -
SetConnMaxLifetime设为 2～5 分钟，强制老化连接，避免僵死连接堆积
怎么确认是连接池争抢，而不是SQL慢
先看现象：同一SQL，在低QPS时快，在高QPS时慢；慢的时候EXPLAIN结果完全一样；慢查询日志里没记录这条SQL——那大概率不是SQL本身的问题。
更直接的方法是查连接池状态：
- 执行
SHOW STATUS LIKE 'Threads_connected'，对比应用配置的SetMaxOpenConns，如果接近或超过，说明连接池已打满 - 在Go里加一行
sqlDB.Stats()，观察WaitCount和WaitDuration是否突增（比如每秒WaitCount > 10，WaitDuration > 30ms） - 抓包或用
netstat -an | grep :3306 | grep TIME_WAIT | wc -l，如果大量TIME_WAIT，说明连接频繁新建/关闭，MaxIdleConns可能过小
PostgreSQL/MySQL驱动错误码怎么区分连接断开
偶发变慢有时其实是连接已断，但GORM没识别出来，还在拿失效连接反复重试。不能靠err != nil就重试，得精准判断是不是网络层断连。
- PostgreSQL：用
errors.As(err, &pqErr)断言*pq.Error，检查pqErr.Code[0:2] == "08"（如"08006"表示连接失败） - MySQL：断言
*mysql.MySQLError，检查myErr.Number() == 2003 || myErr.Number() == 2013 - 通用兜底：错误字符串含
"dial tcp"、"i/o timeout"、"connection refused"，基本可判为连接层问题 - 别在业务层调
gorm.Open()重连——它会新建整个连接池，旧池不Close()就内存泄漏
连接池调参后还要做啥验证
改完参数不是就结束了。生产环境必须加主动探活和可观测性，否则下次还是靠猜。
- 启动后立刻调一次
db.Ping()，确保连接池能建连，失败就 panic 或告警 - 定期（比如每30秒）调
db.DB().Stats()，上报OpenConnections、Idle、WaitCount到监控系统 - 对关键查询加超时控制：
ctx, cancel := context.WithTimeout(ctx, 3*time.Second)，避免一个卡住拖垮整条链路 - 如果用了连接池中间件（比如pgxpool），注意它和GORM原生
*sql.DB池是两套，别混用
连接池不是设了参数就自动健康，它需要被观测、被探测、被限制——最常被忽略的是WaitDuration指标，它比连接数更能反映争抢真实程度。
