sql.DB连接池参数不能runtime修改，因其实现为只读字段且无setter方法，直接赋值不触发内部状态更新；唯一有效方式是重建sql.DB实例并安全切换。
为什么 sql.DB 的连接池参数不能 runtime 修改？
Go 标准库的 sql.DB 在调用 sql.Open 后，其底层连接池（sql.ConnPool）的参数（如 MaxOpenConns、MaxIdleConns、ConnMaxLifetime）是只读的——它们被写入结构体字段后，没有提供任何 setter 方法。试图在运行时“重新配置”只会失败，比如直接赋值 db.MaxOpenConns = 100 看似生效，但实际不触发任何内部状态更新，旧连接仍按原策略复用或淘汰。
动态调整的唯一可行路径：重建连接池
真正起效的方式是新建一个 sql.DB 实例，并把老连接池里的活跃连接逐步 drain 掉。这不是“热更新”，而是可控的冷切换：
- 调用
db.Close()会阻塞直到所有已获取但未释放的*sql.Conn被归还并关闭，但不会中断正在执行的查询；若需更激进控制，应配合上下文超时和应用层连接生命周期管理 - 新
sql.DB创建后，立即设置新参数：newDB.SetMaxOpenConns(200)、newDB.SetMaxIdleConns(50)、newDB.SetConnMaxLifetime(60 * time.Second) - 切换前确保所有业务代码通过统一的 DB 接口（如依赖注入容器或全局变量加锁）访问数据库，避免新老实例混用
如何安全过渡而不中断服务？
关键不是“不重启”，而是让连接自然交接：
- 新
sql.DB初始化后，先将全局变量（如var db *sql.DB）用sync.RWMutex保护，写操作加锁，读操作仅需读锁——避免切换瞬间的竞态 - 不要等老连接全部归还再切换，而是在新实例就绪后，立刻将新 DB 绑定到服务入口；老连接会在后续
Close()或空闲超时后自动退出，新请求全走新池 - 注意
SetConnMaxIdleTime（Go 1.15+）与SetConnMaxLifetime的区别：前者控制空闲连接存活上限，后者控制任意连接（含忙碌中）的最大寿命；动态调参时两者都需同步重设
容易被忽略的副作用：驱动层缓存与 TLS 连接复用
某些数据库驱动（如 pgx/v5 或 mysql）内部维护了额外连接状态，例如 TLS session ticket 缓存、认证 token 复用逻辑。单纯替换 sql.DB 实例无法清空这些缓存，可能导致新连接仍沿用旧参数建立（如错误的 TLS 版本协商）。此时必须：
- 确认驱动是否支持连接池级参数透传；例如
pgxpool.ParseConfig返回的*pgxpool.Config可在每次重建时完全覆盖 - 若使用
database/sql+ 第三方驱动，检查该驱动文档是否暴露底层连接工厂（如driver.Connector），必要时需重建整个sql.Driver实例 - 监控指标如
sql.DB.Stats().OpenConnections和sql.DB.Stats().Idle必须在切换前后分别采集，验证是否真按预期收敛
连接池参数本质是资源水位线，不是配置开关；所谓“动态调整”，实为一次受控的连接池代际更替。漏掉驱动层缓存清理、忽略 sql.DB.Close() 的阻塞语义、或在无锁场景下直接替换全局变量，都会导致参数看似更新成功，实则部分连接仍在旧策略下运行。
