能，但只限制后续新连接，已有连接不受影响且不会主动回收；需配合SetMaxIdleConns、SetConnMaxLifetime等参数协同调优，避免OOM或超时。
Go 的 SetMaxOpenConns 能不能 runtime 修改？
能，但改了不等于立刻生效——它只控制后续新连接的准入上限，已有连接不受影响，也不会主动回收超限的旧连接。
常见错误现象：SetMaxOpenConns(5) 后发现连接数还是 20+，以为没生效；其实是之前已建连的 20 个还在用，池子“撑着”没缩容。
- 调用
SetMaxOpenConns(n)是线程安全的，可随时调用 - 若当前活跃连接数 > 新设值，DB 不会 kill 连接，而是等它们自然 close 或超时
- 真正缩容靠的是后续连接请求被阻塞 + 空闲连接自动回收（受
SetMaxIdleConns和SetConnMaxLifetime影响）
SetMaxOpenConns 和 SetMaxIdleConns 怎么配才不翻车？
两者不是独立参数，是联动关系：idle 连接数不能超过 open 上限，否则 Go 会静默截断到 MaxOpenConns 值。
典型翻车场景：高并发突发后流量回落，idle 连接堆积却无法释放，OOM 风险上升。
立即学习“go语言免费学习笔记（深入）”；
-
SetMaxIdleConns(10)+SetMaxOpenConns(5)→ 实际 idle 最大为 5，多余配置无效 - 推荐组合：
SetMaxOpenConns(20)+SetMaxIdleConns(10)+SetConnMaxIdleTime(5 * time.Minute) - 如果 DB 侧有连接数硬限制（如 MySQL max_connections=100），
MaxOpenConns必须留余量，别顶格设
动态调小 MaxOpenConns 时为什么数据库开始报 dial tcp: i/o timeout？
不是网络问题，是连接池拒绝新建连接，而应用没做重试或降级，直接把错误透出给上层了。
根本原因是：连接池满 + SetMaxOpenConns 调低 → 可用连接槽位更少 → 请求排队超时。
- 默认连接获取超时是无限等待，必须显式设
db.SetConnMaxLifetime和配合context.WithTimeout控制 acquire 行为 - 调小前建议先观察
db.Stats().Idle和.Open，确认空闲连接占比高再动 - 生产环境慎用“突降”，应阶梯式下调（比如每 5 分钟减 2），并监控
db.Stats().WaitCount是否飙升
要不要用第三方库做“智能”连接池伸缩？
不用。Go 标准库 database/sql 的池子本身无“弹性扩缩”逻辑，所有“动态调整”都是被动响应，所谓智能库只是包了一层定时检查 + 条件调用 SetMaxOpenConns 的胶水代码。
真实瓶颈往往不在连接数，而在慢查询、事务未 commit、连接泄漏——这些才是该优先排查的。
- 过度依赖自动伸缩反而掩盖连接泄漏：比如 goroutine 持有
*sql.Conn不放，池子越调越大 - 如果真要响应负载，建议在业务网关层做请求限流，比在 DB 层调连接数更可控
- 唯一值得加的“动态”逻辑是：根据
db.PingContext失败率，临时降MaxOpenConns规避雪崩，但需配套告警
连接池参数不是调参游戏，它反映的是你应用怎么用 DB——查完忘关、事务拖太久、一个请求开十个 conn，再怎么动态也救不回来。
