连接池配置不当会拉高CPU，因其引发高频重连、空转等待或连接泄漏，导致goroutine反复自旋或阻塞唤醒；典型表现为pprof中大量net.(*netFD).Read、runtime.gopark等栈帧，以及数百goroutine卡在semacquire。
为什么连接池配置不当会拉高 CPU
不是连接池本身吃 CPU，而是错误配置触发了高频重连、空转等待或连接泄漏，让 goroutine 在底层驱动里反复自旋或阻塞唤醒。典型表现是 pprof 里看到大量 net.(*netFD).Read、runtime.gopark 或 database/sql.(*DB).conn 相关栈帧，且 go tool pprof http://localhost:6060/debug/pprof/goroutine?debug=2 显示数百个卡在 semacquire 的 goroutine。
查 db.Stats() 看连接池真实水位
别只看监控面板上的“活跃连接数”，它可能被采样延迟或代理层过滤掉。直接在服务内打点调用 db.DB().Stats()，重点关注三个字段：
-
OpenConnections：当前已建立（含空闲+忙）的物理连接数；持续接近MaxOpenConns就危险 -
InUse：正被业务代码持有的连接数；如果长期 > 10 且波动小，大概率有连接没归还 -
WaitCount：因池满而排队等待连接的总次数；非零就说明有请求在等，再结合WaitDuration看是否超时
注意：db.DB().Stats() 是快照，需每 5–10 秒轮询一次，否则看不出趋势。别在 handler 里每次请求都调，加个 time.Ticker 单独 goroutine 上报即可。
确认有没有连接泄漏 —— 关键看 defer rows.Close() 和事务生命周期
GORM 里最隐蔽的泄漏点不是 db.Create，而是显式查询后忘了关 *sql.Rows，或事务没结束。常见场景：
- 用
db.Raw("SELECT ...").Rows()后，没写defer rows.Close()，或写了但rows是 nil 时 panic 跳过 - 手动
tx := db.Begin()后，分支里漏了tx.Commit()或tx.Rollback()，尤其在 error 处理路径上 - 用
db.Session(&gorm.Session{PrepareStmt: true})开启预编译，但 session 对象被意外复用或逃逸到长生命周期结构体里
验证方式：在本地启一个 MySQL，设 wait_timeout = 10，跑压测，然后查 SHOW PROCESSLIST，看有没有状态为 Sleep 且 Time > 10 的连接 —— 那就是没 Close 的残留。
检查 SetConnMaxLifetime 和 SetMaxIdleConns 是否互斥
Go 1.12+ 之后，SetMaxIdleConns(n) 若大于当前 MaxOpenConns 值，会直接 panic，错误是 "max idle conns exceeds max open conns"。但更隐蔽的问题是：设了极短的 SetConnMaxLifetime(5 * time.Second) 却又设了大的 SetMaxIdleConns(50)，结果连接刚空闲下来，还没被复用，就被计时器强制关掉，紧接着新请求又得建新连接 —— 这种“建-关-建”循环会显著抬高 CPU 和系统调用开销。
稳妥做法：
- 先调
db.SetMaxOpenConns(20)，再调db.SetMaxIdleConns(10) -
SetConnMaxLifetime设为比数据库wait_timeout小 5～10 分钟，比如 MySQL 是 300s，这里设240 * time.Second - 禁用
SetMaxIdleTime（Go 1.19+ 新增），除非你明确需要按空闲时长驱逐，否则它和SetConnMaxLifetime叠加容易引发抖动
连接池的“健康”不在于参数多大，而在于连接能稳定复用至少 3 次以上。如果每个连接平均生命周期低于 10 秒，就得回头检查是不是哪里在频繁创建新 *gorm.DB 实例，或者 DSN 里混进了随机参数导致连接无法复用。
