GORM连接池性能差主因是未设SetMaxOpenConns、SetConnMaxLifetime为0、漏掉db.Ping()；需合理配置连接数上限、空闲连接数与生命周期，并确保事务使用tx对象、显式提交及及时关闭资源。
GORM连接池性能差，90%不是框架问题，而是SetMaxOpenConns没设、SetConnMaxLifetime为0、db.Ping()漏掉——这三件事不处理，加再多goroutine也卡在等连接上。
为什么SetMaxOpenConns=0会导致“too many connections”
MySQL默认max_connections是151，而GORM的sql.Open()底层用database/sql，其SetMaxOpenConns(0)含义是“不限制”，不是“用满”。结果就是：服务一压测，连接数瞬间打到200+，MySQL直接报ERROR 1040: Too many connections，P99延迟从50ms跳到800ms+。
- 查数据库真实上限：
SHOW VARIABLES LIKE 'max_connections';，假设返回200 →SetMaxOpenConns应设为120～160（60%～80%） - 云数据库（如阿里云RDS）更保守：按每CPU核≈20连接估算，4核就设80，别硬套物理机配置
- 设太低（比如10）：20个并发请求全卡在
acquireConn，QPS上不去，平均延迟反而升高
SetMaxIdleConns和SetConnMaxLifetime必须配对用
只调SetMaxIdleConns不设SetConnMaxLifetime，等于让空闲连接赖在池子里不走。云环境NAT网关或防火墙3～5分钟后静默断连，下次复用直接报read: connection reset by peer。
-
SetMaxIdleConns一般设为SetMaxOpenConns的1/2～2/3（如最大100 → 空闲设40～60） -
SetConnMaxLifetime推荐2～5分钟：云数据库主备切换快，设2分钟更安全；自建MySQL可设5分钟 - 千万别设成0或
time.Hour：长期存活连接易在DB侧积压idle in transaction，锁资源、占内存、触发上下文切换风暴
初始化后必须立刻db.Ping()，否则首请求必崩
gorm.Open()只是初始化连接池结构，不建真实连接。很多服务日志写着“DB initialized”，其实第一笔查询才真正拨号——这时候网络不通、密码错、DNS失败，全堆在首请求上，导致首屏白屏或超时。
- 必须紧接
db, err := gorm.Open(...)之后写：if err := db.Ping(); err != nil { /* 记录并退出 */ } - 同理，若用
sql.Open()，也要db.Ping()，否则无法提前暴露驱动层问题 - 配合
db.Stats()定期打点：重点关注InUse（是否长期>95%）、Idle（是否长期≈0）、WaitCount（是否持续上涨）
事务里混用db.Query和tx.Query会悄悄泄漏连接
事务内调db.Query()会从全局池另取一个连接，既不参与当前事务，又占着连接不放。现象是db.Stats().InUse持续高位、WaitCount不涨但DB连接数缓慢爬升，最终Too many connections。
- 所有SQL必须走
tx实例：tx.Query()、tx.Exec()才复用事务绑定的连接 -
sql.Tx必须显式Commit()或Rollback()，漏写=连接泄漏 - 开启事务必须带context：
db.BeginTx(ctx, &sql.TxOptions{})，其中ctx建议设5s超时
最容易被忽略的从来不是参数值该填多少，而是rows.Close()漏写、tx忘提交、db.Ping()没做——这些比毫秒级的SetConnMaxLifetime误差更容易让服务凌晨挂掉。
