GORM连接池性能问题主因是参数未对齐数据库上限、缺健康检查及空闲生命周期配置：SetMaxOpenConns应设为MySQL max_connections的60%～80%，SetMaxIdleConns为1/2～2/3，SetConnMaxLifetime为2～5分钟，并必须调用db.Session(&gorm.Session{}).Ping()验证连接。
GORM连接池配错，90%的性能问题和偶发超时都出在这里——不是代码写得不好，是连接池没对齐数据库上限、没做健康检查、没设对空闲生命周期。
SetMaxOpenConns 必须和 MySQL max_connections 对齐
这个值不是凭经验拍的。MySQL 实例的 max_connections 是硬上限，GORM 的 SetMaxOpenConns 超过它，第一笔并发查询就会报 Too many connections；设太低，又卡住 goroutine 等连接，P99 延迟飙升。
- 查当前 MySQL 限制：
SHOW VARIABLES LIKE 'max_connections';（比如返回 200） - 推荐设为 60%～80%，即
120～160：留余量给备份、监控、其他服务，也防流量毛刺 - 云数据库（如阿里云 RDS）更保守：按每核 ≈20 连接估算，别套物理机配置
- 常见错误：
SetMaxOpenConns(0)（等于不限制，直接撞上限）、SetMaxOpenConns(500)（远超 MySQL 默认 151，必爆）
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 * time.Minute更适合云数据库（主备切换快），5 * time.Minute可用于自建 MySQL - 千万别设成
0或time.Hour：长期存活连接易在 DB 侧积压idle in transaction，锁资源、占内存、触发上下文切换风暴
启动时必须调用 db.Session(&gorm.Session{}).Ping()
gorm.Open() 只初始化连接池结构，不建真实连接。很多服务日志写着 “DB initialized”，其实第一笔查询才真正拨号——这时候网络不通、密码错、DNS 解析失败，全堆在首请求上，导致首屏白屏或接口 500。
- GORM v2 中
db.Ping()已弃用，必须用db.Session(&gorm.Session{}).Ping() - 必须紧接在
gorm.Open()后执行，并检查 error；失败就 panic 或 log.Fatal，不能忽略 - 漏掉这步，本地开发可能正常（连接快），上线后因网络策略、RDS 安全组、VPC 配置等立刻暴露问题
不同数据库对连接池参数敏感度差异大
MySQL 和 PostgreSQL 对 max_connections 限制较严格；SQLite 是文件级，根本不适用连接池；达梦、TiDB 等国产库虽兼容 MySQL 协议，但默认连接数上限常更低（如达梦默认仅 100），必须单独确认。
- TiDB：查
SELECT VARIABLE_VALUE FROM mysql.tidb WHERE VARIABLE_NAME = 'max_connections'; - 达梦：查
SELECT SF_GET_PARA_VALUE(1, 'MAX_SESSIONS');，若为 100，则 GORMSetMaxOpenConns最高只能设 80 - PostgreSQL：查
SHOW max_connections;，注意其连接消耗比 MySQL 更重，建议更保守（如设为上限的 50%～60%）
连接池不是“设了就完事”的配置项，它是一组需要对齐数据库能力、匹配部署环境、并经验证的联动参数。最容易被忽略的是 db.Session(&gorm.Session{}).Ping() 和 SetConnMaxLifetime 的组合——没它们，连接池只是个纸糊的架子，一碰就散。
