SetMaxOpenConns设为0表示不限制最大打开连接数，但实际受系统文件描述符、数据库服务端max_connections及Go调度能力制约，生产环境严禁使用，应结合DB配置设定合理上限。
SetMaxOpenConns 设为 0 会怎样
设为 0 表示不限制最大打开连接数，但实际行为是「不主动限制」，而非「无限供应」。底层仍受操作系统文件描述符、数据库服务端连接上限（如 MySQL 的 max_connections）、以及 Go runtime 的 goroutine 调度能力制约。压测中常见现象是：QPS 上不去、大量 context deadline exceeded 或 dial tcp: lookup xxx: no such host（DNS 崩溃），本质是连接创建失败或超时堆积。
实操建议：
- 永远不要在生产环境设
SetMaxOpenConns(0)，哪怕测试阶段也要明确上限 - 若想“尽量多连”，应结合数据库侧配置调优，比如先确认 MySQL 的
max_connections是 500，再设SetMaxOpenConns(400) - 注意：设为
0后，sql.DB.Stats().OpenConnections仍会增长，但可能卡在net.Dial阶段失败，不体现在连接池内
压测时 QPS 不随 MaxOpenConns 线性增长的真正原因
很多人预期“翻倍设 SetMaxOpenConns 就能翻倍吞吐”，但压测常显示收益递减甚至停滞。这不是 bug，而是连接池只是瓶颈之一。当 SetMaxOpenConns 超过某阈值后，瓶颈往往转移到：
- 数据库单核 CPU 已打满（尤其复杂查询）
- 磁盘 I/O 或网络带宽饱和（例如大字段读写）
- Go 应用自身 GC 压力变大（大量连接对象 + rows 扫描导致堆增长）
- 连接复用率下降：设过大后，空闲连接积压，新请求反而要等
SetConnMaxLifetime触发重建，增加延迟
典型表现：从 50 → 100 提升明显，但从 200 → 400 QPS 几乎不变，P95 延迟却上升 20%。
与 SetMaxIdleConns 的协同关系必须理清
SetMaxOpenConns 和 SetMaxIdleConns 不是独立参数，它们共同决定连接生命周期和复用效率。压测中常见误配：
-
SetMaxOpenConns(100)+SetMaxIdleConns(99)：几乎不留新连接空间，高并发下大量请求阻塞在acquireConn，报错sql: connection pool exhausted -
SetMaxOpenConns(100)+SetMaxIdleConns(0)：每次用完立刻关连接，相当于没池化，压测延迟陡增、CPU 消耗翻倍 - 合理配比：一般
SetMaxIdleConns设为SetMaxOpenConns的 60%~80%，且不超过SetMaxOpenConns
另外注意：SetMaxIdleConns 对 PostgreSQL 影响更敏感（因连接建立开销更大），MySQL 相对宽容。
真实压测中推荐的初始配置组合
没有银弹配置，但可基于典型 OLTP 场景（单表 CRUD、平均响应
- 数据库侧先确认：MySQL
max_connections >= 300，PostgreSQLmax_connections >= 200 - 应用侧初始设：
db.SetMaxOpenConns(100)、db.SetMaxIdleConns(70)、db.SetConnMaxLifetime(30 * time.Minute) - 压测时观察两个关键指标：
sql.DB.Stats().WaitCount（非零说明排队）和sql.DB.Stats().MaxOpenConnections（是否长期打满） - 若
WaitCount持续上涨，优先调高SetMaxOpenConns；若MaxOpenConnections峰值仅到 40，说明瓶颈不在连接池，该查 SQL 或索引了
连接池参数不是调优终点，而是排查 IO 瓶颈的第一把尺子——它暴露问题，但不解决根本问题。
