GORM连接池吞吐量低主因是未调优database/sql默认参数。需设SetMaxOpenConns（建议峰值QPS×耗时×1.5，不超过MySQL max_connections的70%），配对设置SetMaxIdleConns（Open的1/2～2/3）与SetConnMaxLifetime（2～5分钟）、SetConnMaxIdleTime（略小于Lifetime），并用db.Stats()监控WaitCount、InUse等指标，事务中禁用db.Query而须统一用tx对象。
GORM连接池吞吐量上不去，90%是因为没动过默认参数，而不是代码写得差。 它本身不管理连接，只是database/sql的封装，所有性能瓶颈都落在底层*sql.DB配置上。不显式调参，高并发下必然卡在“等待连接”或“连接被MySQL主动断开后疯狂重连”上。
SetMaxOpenConns必须设非零值，否则MySQL直接被打满
默认SetMaxOpenConns(0)等于不限制，但MySQL服务端max_connections通常只有151（默认值），QPS一上来就报too many connections。这不是GORM的锅，是连接池失控。
- 计算公式：峰值 QPS × 平均查询耗时（秒）× 1.5，再取整；例如 QPS=400、平均耗时 30ms → 400 × 0.03 × 1.5 ≈ 18，建议设为20～30
- 硬上限：不超过数据库
max_connections的70%，比如 MySQL 是 151，就别超过 100 - 线上必须加
db.Ping()校验，否则启动失败静默，接口一调就panic: invalid connection
SetMaxIdleConns和SetConnMaxLifetime要配对设，单设一个等于白干
只设SetMaxIdleConns(20)不设SetConnMaxLifetime，空闲连接永不过期，MySQL主备切换后旧连接还在池里发心跳，不断触发重连风暴；反过来只设SetConnMaxLifetime(time.Hour)却不控空闲数，每次请求都新建连接，销毁开销反而更大。
-
SetMaxIdleConns建议为SetMaxOpenConns的 1/2～2/3（如 Open=100 → Idle=50） -
SetConnMaxLifetime设 2～5 分钟，云数据库（RDS/PolarDB）建议缩到 3～5 分钟，适配主备切换 - 必须同时设
SetConnMaxIdleTime（Go 1.15+），且值要小于SetConnMaxLifetime，常见组合是3m和5m
查连接池真实状态不能靠猜，得盯db.Stats()三个字段
不看db.Stats()就调参，和闭眼开车没区别。它返回的是实时运行态，不是快照——你要看趋势，不是单次值。
-
WaitCount持续上涨 → 连接不够用，优先加SetMaxOpenConns -
InUse == MaxOpenConns且长期不回落 → 连接借出没归还，检查rows.Close()是否漏写、事务是否没Commit()/Rollback() -
MaxIdleClosed > 0且频繁增长 → 空闲连接回收太激进，提高SetMaxIdleConns或延长SetConnMaxIdleTime
事务里千万别混用db.Query和tx.Query
在tx, _ := db.Begin()里调db.Query，等于从全局池另开一个连接执行，既不参与事务，又额外占坑。更糟的是，这个连接可能被其他 goroutine 拿去干别的事，导致数据不一致或死锁。
- 事务内所有数据库操作必须统一走
tx对象，包括tx.Find()、tx.Exec() - 记得给
tx加context.WithTimeout，避免长事务拖垮整个池 - 别依赖GORM自动回滚——
defer tx.Rollback()必须显式写，且只在tx.Commit()前生效
真正难的不是记住这几个参数，而是理解它们之间的约束关系：Idle数不能超Open数，IdleTime必须短于Lifetime，WaitCount上升时先看InUse是否打满而非盲目加Open。这些数字背后是MySQL线程模型、Go调度器与网络超时的三方博弈，调参只是把它们拉回平衡点。
