SetMaxOpenConns 设过高会因空闲连接占用数据库线程/内存、加剧上下文切换，导致P99延迟飙升；应按「峰值QPS×平均耗时」的1.5–2倍设置，并配合MaxIdleConns、ConnMaxLifetime等参数优化。
为什么 SetMaxOpenConns 设太高反而拖慢响应？
很多开发者看到高并发就盲目调大 SetMaxOpenConns，结果发现 P99 延迟飙升、数据库 CPU 扛不住。根本原因不是连接不够，而是连接池和数据库的协同失衡：过多空闲连接长期占用 DB 侧资源（如内存、线程、锁），尤其在 PostgreSQL 或 MySQL 中，每个连接对应一个服务端线程/进程，容易触发连接数上限或上下文切换开销。
实操建议：
-
SetMaxOpenConns值建议设为「峰值 QPS × 平均查询耗时（秒）」的 1.5–2 倍，例如 QPS=200、平均查询 50ms → 200 × 0.05 = 10，再乘 1.5 ≈ 15；不超过数据库max_connections的 70% - 务必配合
SetMaxIdleConns，通常设为与SetMaxOpenConns相同或略低（如 10–15），避免空闲连接堆积却不复用 - 启用
SetConnMaxLifetime（如 30m）和SetConnMaxIdleTime（如 5m），强制回收老化连接，防止因网络抖动或 DB 重启导致的 stale connection 报错（如"server closed the connection"）
如何识别连接池正在“假忙”？
程序日志里没报错，但接口变慢、DB 监控显示连接数稳定在高位、pg_stat_activity 或 SHOW PROCESSLIST 里大量 idle in transaction 或 sleep 状态——这是典型的“连接被借出但没归还”。常见于 defer rows.Close() 漏写、panic 后未恢复、或事务中嵌套查询未统一管控。
快速定位方法：
