go 的 sql.db 不支持真正动态调整连接池参数，调用 setmaxopenconns 等方法仅限制后续新建连接，不回收现有连接，也不重置计时器；安全变更需重建 sql.db 实例并灰度迁移流量。
为什么不能直接修改 sql.DB 的连接池参数
Go 标准库的 sql.DB 一旦初始化，其底层连接池参数（如 MaxOpenConns、MaxIdleConns、ConnMaxLifetime）就无法通过公开 API 动态覆盖。调用 db.SetMaxOpenConns(n) 等方法虽不报错，但仅影响后续新建连接的行为，已有空闲连接、正在使用的连接不受控，且参数变更不会“立即生效”——比如减小 MaxOpenConns 后，已打开的连接仍会维持，直到被主动关闭或超时。
SetMaxOpenConns 和 SetMaxIdleConns 的真实行为边界
这两个方法本质是设置内部字段并触发一次轻量同步，但它们不驱逐连接、不中断活跃事务、也不重置计时器。实际效果取决于当前连接池状态：
-
SetMaxOpenConns(5)后，若已有 10 个打开连接，新请求仍可复用其中 5 个；第 6 个空闲连接在下次被Put回池时会被立即关闭 -
SetMaxIdleConns(2)不会立刻清理掉当前 8 个空闲连接，而是从下一次Put开始执行“只留最多 2 个”的策略 -
SetConnMaxLifetime只影响此后新建连接的生命周期计时起点，已有连接继续按旧值倒计时
安全动态调整的唯一可行路径：重建连接池
真正实现“动态参数调整”，必须创建新 sql.DB 实例并逐步迁移流量。关键不是“能不能改”，而是“怎么切得稳”：
- 先用新参数创建备用
sql.DB，调用PingContext验证连通性 - 通过中间层（如自定义
DBRouter）控制读写路由：初始将 1% 流量导向新池，观察错误率与延迟 - 使用
db.Close()主动关闭旧池——它会等待所有正在使用的连接归还后才真正释放资源，因此需配合超时控制（例如用context.WithTimeout包裹业务操作） - 避免在 HTTP handler 中直接替换全局
*sql.DB变量，应配合 sync.Once 或原子指针更新 + 读取端 double-check
容易被忽略的底层细节：驱动层是否支持热重载
某些数据库驱动（如 pgx/v5 的 stdlib 封装）在 sql.Open 时会缓存连接参数，而 mysql 驱动则对 timeout 类参数更敏感。即使你重建了 sql.DB，若 DSN 字符串里硬编码了 readTimeout=30s，新池仍继承该值——动态调整必须同时控制 DSN 构造逻辑和连接池参数。
最稳妥的做法是把 DSN 拆解为结构体，每次重建前重新拼接，并确保所有连接级配置（如 parseTime=true、loc=UTC）与参数一致，否则可能引发时区解析异常或时间戳截断。
