正确配置需协同SetMaxOpenConns（设为MySQL max_connections的60%~80%，如200则配120~160）、SetMaxIdleConns（为其1/2~2/3）与SetConnMaxLifetime（云环境推荐2~5分钟），并用db.Stats()实时监控InUse、Idle、WaitCount水位，初始化后必须调用db.Ping()验证连通性。
连接池参数设错比没设更危险——SetMaxOpenConns设成0或远超MySQL max_connections，线上会直接报Too many connections；设太低又卡住并发，QPS掉一半。调参不是拍脑袋，得测、得看、得配对。
怎么用 db.Stats() 实时看连接池真实水位
别只盯着日志里有没有报错，db.Stats() 返回的才是连接池当前状态。它暴露三个关键字段：InUse（正在被业务 goroutine 持有的连接数）、Idle（空闲待复用的连接数）、WaitCount（因池满而排队等待连接的总次数）。
-
InUse长期 >95%：说明连接不够用，要么加大SetMaxOpenConns，要么查是不是有长事务或连接泄露 -
Idle长期接近 0：空闲连接全被耗尽，新请求进来大概率要新建连接，延迟抖动明显 -
WaitCount持续上涨：连接池已成瓶颈，必须扩容或优化查询并发模型 - 建议每10秒打一次点，用 Prometheus 抓取，不要只靠启动时看一眼
SetMaxOpenConns 和 max_connections 怎么对齐
查 MySQL 实际上限：SHOW VARIABLES LIKE 'max_connections';。假设返回 200，SetMaxOpenConns 就该设 120～160（60%～80%），不是“能用多少就设多少”。
- 云数据库（如阿里云 RDS）更保守：按每核 ≈20 连接估算，比如 4 核实例，上限设 80 左右
- 设成 0：MySQL 驱动默认不限，高并发下瞬间打爆 DB，P99 延迟从 50ms 拉到 800ms+
- 设成 500：DB 直接拒绝新连接，所有请求卡在
db.First等待，错误日志刷屏Too many connections - 主从分离场景下，主库和每个从库都要单独算：主库连接池通常更小（写压力低但一致性要求高），从库可稍大（读多写少）
为什么 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，锁资源、占内存、触发上下文切换风暴 -
SetConnMaxIdleTime（Go 1.15+）建议设 30m～1h，防止长期空闲连接白占资源
初始化后漏掉 db.Ping() 是首屏白屏元凶
gorm.Open() 或 sql.Open() 只是初始化连接池结构，不建真实连接。很多服务日志写着 “DB initialized”，其实第一笔查询才真正拨号——这时候网络不通、密码错、DNS 解析失败，全堆在首请求上，前端直接白屏或超时。
- 必须紧接
db, err := gorm.Open(...)后面加db.DB().Ping()，并检查err - 如果用
db, err := sql.Open(...)，同样要db.Ping()，否则无法提前暴露底层驱动问题 - 读写分离场景下，主库和每个从库都得各自
Ping()，不能只 ping 主库就认为全通 - 测试时故意把 DSN 写错，验证 panic 是否如期发生——这才是上线前该做的底线检查
连接池不是设完就一劳永逸。真实流量下的 InUse 波峰、从库延迟突增、主备切换后的连接复用失败……这些细节往往藏在 db.Stats() 的微小波动里，而不是错误日志中。
