不能只靠默认连接池参数，因为GORM的gorm.Open返回gorm.DB不建连且不限流，底层sql.DB的SetMaxOpenConns默认0（无上限）、SetMaxIdleConns默认2，高并发易触发MySQL“Too many connections”，低流量则频繁建连增延迟。
为什么不能只靠默认连接池参数
GORM 的 gorm.Open 返回的是 *gorm.DB，它不直接建连，也不限制连接数——底层 *sql.DB 的 SetMaxOpenConns 默认是 0（无上限），SetMaxIdleConns 默认是 2。这意味着：高并发压测时，连接可能瞬间打满数据库的 max_connections（比如 MySQL 默认 151），触发 “Too many connections” 错误；而低流量服务却可能因空闲连接过少，频繁新建/销毁连接，增加延迟。
怎么根据并发量估算 MaxOpenConns
别拍脑袋设 100 或 200，得结合实际请求特征算：
- 先确认数据库侧最大允许连接数：
SHOW VARIABLES LIKE 'max_connections';（MySQL）或对应命令 - 预留 20% 给 DBA 巡检、备份、慢查分析等后台任务
- 按接口平均耗时和 QPS 粗估活跃连接需求：假设峰值 QPS 是 300，平均 SQL 耗时 150ms，则理论活跃连接 ≈ 300 × 0.15 = 45
- 再叠加业务冗余：比如有定时任务、后台导出、多库分片共用同一数据库实例等情况，建议上浮 1.5～2 倍 → 最终
SetMaxOpenConns(80)比较稳妥
注意：这个值不是越大越好。超过数据库承载能力，连接会被拒绝；远低于实际负载，会排队等待，表现为 P99 延迟突增。
SetMaxIdleConns 和 SetConnMaxIdleTime 怎么配
这两个参数管“空闲连接”，影响连接复用效率和资源释放节奏：
-
SetMaxIdleConns(n)：建议设为SetMaxOpenConns的 1/2～2/3（如 Open=80 → Idle=40）。设太小（比如 5），每次波峰过后连接全被回收，下次请求又要重建；设太大（比如 75），空闲连接长期占着 DB 连接槽位，可能挤占其他服务 -
SetConnMaxIdleTime(30 * time.Minute)：强制空闲超 30 分钟的连接关闭。避免数据库端wait_timeout（MySQL 默认 8 小时）比客户端更长，导致客户端拿到已断开的“僵尸连接” - 必须在
gorm.Open后立即调用，且要在首次查询前完成配置 —— 因为连接池初始化发生在第一次db.First等操作时
验证连接池是否生效的关键动作
很多人配完就以为万事大吉，结果线上还是连不上。真正起作用的只有两件事：
- 调
db.DB().Ping()：这是唯一能触发真实建连并校验通路的方法。仅靠gorm.Open成功返回，不代表 DB 可达 - 监控
db.DB().Stats()：在关键路径（如 HTTP middleware）里定期打点，看OpenConnections、IdleConnections是否符合预期。突然飙升到MaxOpen且降不下去，大概率是事务没 Close 或连接泄漏 - 别忘了设
SetConnMaxLifetime(7 * time.Hour)：比 MySQL 的wait_timeout少 1 小时，主动淘汰老化连接，避免半夜批量任务触发大量重连
连接池参数不是写一次就一劳永逸的配置项，它得跟着业务增长、DB 规格变更、慢查询优化同步调整。最常被忽略的是：没在 Ping() 后立刻配参，导致部分连接按默认值初始化，混在池里长期存在。
