maxopenconns 应根据数据库负载和业务qps×耗时×1.5估算，避免盲目设高；maxidleconns需≤maxopenconns并配合connmaxlifetime与connmaxidletime控制连接生命周期，防止陈旧连接引发错误。
MaxOpenConns 设多少才不拖垮数据库
别盲目设成 100 或 1000 —— MaxOpenConns 是连接池能同时打开的最大连接数，它直接对应数据库侧的并发连接压力。MySQL 默认 max_connections 通常为 151，线上若多个服务共用一个实例，或单个服务部署多实例，总连接数很容易超限，触发 ERROR 1040: Too many connections。
实操建议：
- 先查数据库当前负载：
SHOW STATUS LIKE 'Threads_connected';，再结合 QPS 和平均查询耗时估算峰值并发连接需求 - 对读多写少的服务，
MaxOpenConns建议设为「预期峰值 QPS × 平均响应时间（秒）× 1.5」，例如 QPS=200、平均耗时 50ms → 200 × 0.05 × 1.5 ≈ 15 - 上线后紧盯 MySQL 的
Aborted_connects和应用层的dial tcp: i/o timeout，这两者常是连接池过载的早期信号
MaxIdleConns 不是越大越好，闲置连接会卡住资源
MaxIdleConns 控制池中“空闲但未关闭”的连接上限。设太高会导致大量连接长期空占 MySQL 线程和内存，尤其在流量波峰波谷明显时（比如定时任务触发瞬间高峰后回落），这些 idle 连接不会自动释放，直到下次被复用或超时。
关键点：
-
MaxIdleConns必须 ≤MaxOpenConns，否则 Go 会静默截断为MaxOpenConns值，不报错也不警告 - 日常流量稳定的服务可设为
MaxOpenConns的 60%~80%；波动大的场景建议压低到 20%~40%，靠SetConnMaxLifetime和SetConnMaxIdleTime配合回收 - MySQL 5.7+ 默认
wait_timeout = 28800（8 小时），但 Go 的 idle 连接若超过SetConnMaxIdleTime（推荐设 30m~1h），会被主动 close，避免被 DB server kill 导致下次ping失败
必须配齐的三个超时参数：ConnMaxLifetime / ConnMaxIdleTime / SetMaxOpenConns
只调 MaxOpenConns 和 MaxIdleConns 是半套配置。缺少生命周期控制，连接池会在后台持续持有陈旧连接，遇到数据库重启、主从切换、网络抖动时，第一个请求大概率报 invalid connection 或 connection refused。
标准组合写法（Go 1.15+）：
db, _ := sql.Open("mysql", dsn)
db.SetMaxOpenConns(20)
db.SetMaxIdleConns(10)
db.SetConnMaxLifetime(1 * time.Hour) // 强制重连前最大存活时间
db.SetConnMaxIdleTime(30 * time.Minute) // 空闲超时后自动 close
注意：SetConnMaxLifetime 不是“连接保活”，而是“到期作废”；SetConnMaxIdleTime 才真正决定空闲连接何时被清理。两者都设了，才能兼顾稳定性与资源释放节奏。
验证连接池是否生效：看指标，别信日志
很多开发者加了 log.Println("connected") 在 sql.Open 后就以为池建好了——其实 sql.Open 只是初始化，真正建连发生在第一次 db.Query 或 db.Ping 时。
真要确认池行为，得盯这些地方：
- MySQL 侧执行
SHOW PROCESSLIST，观察Command列是否大量出现Sleep（idle 连接），且数量稳定在MaxIdleConns附近 - 应用侧打点监控
db.Stats().OpenConnections和db.Stats().Idle，画成时序图，看波峰时 Open 是否逼近MaxOpenConns，Idle 是否随流量下降而回落 - 故意把
MaxOpenConns设成 1，然后并发发 5 个请求，如果第 2 个开始明显延迟（>100ms），说明排队机制起了作用 —— 这才是池在工作
连接池不是开箱即用的魔法，它是数据库和应用之间一层有状态的缓冲，配置值背后全是资源权衡。调参没标准答案，只有观测、反馈、再调整这一条路。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
