setmaxopenconns应设为数据库max_connections的60%～80%，兼顾qps、平均耗时与余量，并配合setmaxidleconns（1/2～1/3）、setconnmaxlifetime（10～30分钟）和setconnmaxidletime（5～10分钟）协同调优。
SetMaxOpenConns 设为多少才不拖慢请求
设太高不等于性能好，反而可能压垮数据库或触发连接数限制。关键看你的数据库最大允许连接数、单次请求耗时、并发峰值这三者的关系。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 先查数据库侧上限：
SHOW VARIABLES LIKE 'max_connections';（MySQL）或SELECT setting FROM pg_settings WHERE name = 'max_connections';（PostgreSQL） -
SetMaxOpenConns通常设为该值的 60%～80%，留余量给后台任务、其他服务或突发流量 - 如果应用 QPS 是 100，平均 DB 耗时 20ms，理论最小连接数 ≈ 100 × 0.02 = 2；但必须叠加安全余量，别按理论值硬算
- 线上观察
sql.DB.Stats().OpenConnections，持续接近SetMaxOpenConns就说明不够用；长期远低于 50% 可能设高了
SetMaxIdleConns 和 SetConnMaxLifetime 必须配对调
只调 SetMaxOpenConns 不碰 idle 和 lifetime，很容易在长连接场景下遇到“连接已断开但还被复用”的错误，比如 MySQL 的 ERROR 2013 (HY000): Lost connection to MySQL server during query。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
-
SetMaxIdleConns建议 ≤SetMaxOpenConns，一般设成后者的 1/2～1/3；设太高会导致空闲连接堆积，占用 DB 资源却不干活 -
SetConnMaxLifetime推荐 10～30 分钟（如30 * time.Minute），避免连接因数据库侧超时被静默断开 - 搭配
SetConnMaxIdleTime（Go 1.15+）一起用：设为 5～10 分钟，让空闲太久的连接主动释放，防止 NAT 超时或防火墙踢掉
为什么 DB.Ping() 成功但查询仍报错 dial tcp: i/o timeout
因为 Ping() 只检测连接池里有没有可用连接，不保证下次 Query() 时那个连接还活着——尤其当 SetConnMaxLifetime 没设，或数据库重启过，老连接就卡在 idle 池里发呆。
常见错误现象：
- 服务刚启动时一切正常，跑几小时后开始零星报
dial tcp: i/o timeout或read: connection reset by peer -
DB.Stats()显示Idle连接数很高，WaitCount却在缓慢上涨
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 务必启用
SetConnMaxIdleTime，别依赖默认值（0 表示永不过期） - 加一层简单健康检查：在 HTTP handler 开头执行
db.QueryRow("SELECT 1").Scan(&dummy)，比Ping()更贴近真实路径 - 如果用云数据库（如 AWS RDS、阿里云 PolarDB），注意它们自带连接中断策略，
ConnMaxLifetime必须比它的 idle timeout 小至少 2 分钟
Go 1.19+ 的 sql.OpenDB 和 driver.ConnPool 接口要不要碰
除非你在写自定义驱动或做极致连接控制，否则不用碰。标准 sql.Open + Set* 系列方法已经覆盖 99% 场景，强行实现 driver.ConnPool 容易引入死锁或泄漏。
容易踩的坑：
- 自己实现
Get/Put时没处理 context cancel，导致 goroutine 泄漏 - 误以为
sql.OpenDB能绕过连接池初始化逻辑，其实它只是延迟到第一次Query才建池，参数设置方式完全一样 - 升级 Go 版本后发现
SetMaxOpenConns(0)含义变了（现在表示“无限制”，旧版是“不限制但行为未定义”），生产环境千万别设 0
复杂点在于：连接池参数不是孤立生效的，它和 DNS 解析缓存、TLS 握手耗时、甚至你用的 proxy（如 ProxySQL）的连接复用策略都会互相影响。调参前先确认链路里谁在真正管理连接生命周期。
