设置过高不会导致连接泄漏，但会引发数据库拒绝连接；真正泄漏源于未调用rows.Close()或tx.Commit()/Rollback()；合理配置需使ConnMaxLifetime≥平均耗时×3且≤数据库超时，MaxIdleConns设为MaxOpenConns的0.3～0.5。
MaxOpenConns 设置过高会导致连接泄漏还是数据库拒绝连接？
设置 MaxOpenConns 过高本身不会直接导致连接泄漏，但会显著增加数据库端的并发连接压力。当应用实例多、每个实例都设为 100+，而数据库最大连接数（如 MySQL 的 max_connections）只有 200，就极易触发 ERROR 1040: Too many connections。
真正引发泄漏的是未正确调用 rows.Close() 或 tx.Commit()/Rollback()，让连接长期处于“已打开但未归还”状态——此时即使 MaxOpenConns 设为 10，也可能因泄漏耗尽全部可用连接。
-
MaxOpenConns建议值 ≈ 数据库总连接上限 ÷ 应用实例数 × 0.7～0.8（留缓冲） - 上线前务必压测：用
ab或hey模拟真实 QPS，观察数据库SHOW STATUS LIKE 'Threads_connected'是否稳定 - 监控关键指标：若
sql.DB.Stats().OpenConnections长期接近MaxOpenConns，且InUse波动小、Idle持续为 0，大概率存在泄漏或查询阻塞
SetMaxIdleConns 和 SetConnMaxLifetime 怎么配才不互相打架？
这两个参数常被误配成矛盾关系：比如设 MaxIdleConns=50 却把 ConnMaxLifetime=5s，结果连接刚放进空闲池就被立刻销毁，空闲池形同虚设，所有请求都走新建连接路径，徒增 TLS 握手和认证开销。
合理配合的核心是：让连接在空闲池中“活够时间”，又能及时淘汰老化连接。
立即学习“go语言免费学习笔记（深入）”；
-
ConnMaxLifetime应 ≥ 单次业务平均耗时 × 3，且 ≤ 数据库侧连接超时（如 MySQLwait_timeout默认 28800s，但通常设为 1～2 小时更稳妥） -
MaxIdleConns一般设为MaxOpenConns × 0.3～0.5；若应用读多写少、查询极快（ - 必须同时设
SetMaxIdleTime(30s)（Go 1.15+），否则空闲连接永不回收，可能堆积大量已过期但未关闭的连接
为什么用了连接池，pprof 还显示大量 *net.TCPConn 创建？
这通常说明连接池没真正复用起来。常见原因不是参数错，而是代码绕过了池子：
- 频繁调用
sql.Open()创建新*sql.DB实例（应全局复用一个） - 使用
db.ExecContext(ctx, ...)但 ctx 带了短超时（如 100ms），导致连接在归还前就被上下文取消，驱动强制关闭并丢弃该连接 - 事务中执行长耗时非 SQL 操作（如 HTTP 调用、文件读写），使连接长时间被占用，空闲池持续饥饿，新请求只能新建连接
验证方式：在初始化后立即打点
db.SetConnMaxLifetime(1 * time.Hour) db.SetMaxOpenConns(20) db.SetMaxIdleConns(10) db.SetMaxIdleTime(30 * time.Second) // 然后检查 db.Stats() 中 Idle 和 InUse 是否随流量自然波动
云数据库（如 AWS RDS、阿里云 PolarDB）要额外注意什么？
云数据库普遍对连接数更敏感，且底层有代理层或连接池（如 PolarDB 的 Proxy），会叠加一层超时与限制。
- AWS RDS 的
max_connections是按实例规格硬限制，但实际建议值往往比标称值低 15%～20%，因为 RDS 自身要占用部分连接 - 阿里云 PolarDB 开启“连接池模式”（即 PgBouncer 兼容层）后，应用端
MaxOpenConns应设为 5～10，避免穿透代理直连后端节点 - 所有云环境都必须启用
SetConnMaxLifetime，防止连接被中间网络设备（如 NLB、SLB）静默断开后，应用仍尝试复用已失效的 socket
最易被忽略的一点：云厂商控制台看到的“当前连接数”包含后台线程、复制连接等，不等于你应用能用的连接数。真实可用数得查 SHOW PROCESSLIST 并过滤掉 User 为 rdsadmin 或 system user 的行。
