MaxOpenConns设为0表示无限制，易致MySQL“Too many connections”；设为负数则被忽略并退化为0；生产环境须显式设合理上限（如120），并配合SetMaxIdleConns和SetConnMaxLifetime调优，且需通过db.Ping()和db.Stats()验证与监控。
连接池 MaxOpenConns 设为 0 或负数会怎样
Go 的 database/sql 包中，MaxOpenConns 为 0 表示无限制，这在高并发下极易耗尽数据库连接数，触发 MySQL 的 Too many connections 错误；设为负数则被忽略，退化为默认值（即 0），等同于开闸放水。生产环境必须显式设置合理上限。
- 典型误配：
db.SetMaxOpenConns(0)—— 看似“不限制”，实则把压力全甩给数据库 - 合理范围：一般设为数据库最大连接数的 60%～80%，例如 MySQL
max_connections = 200，则SetMaxOpenConns(120) - 注意：该值不是越大越好，超过数据库承载能力反而引发排队、超时、连接拒绝
SetMaxIdleConns 和 SetConnMaxLifetime 配合不当的后果
闲置连接过多且长期不释放，会占用数据库资源却未被复用；而生命周期过短又导致频繁建连销毁，抵消连接池收益。两者需协同调优：
-
SetMaxIdleConns(20)建议 ≤MaxOpenConns，通常设为后者的 1/3～1/2（如MaxOpenConns=120→MaxIdleConns=40） -
SetConnMaxLifetime(1h)推荐设为略小于数据库端wait_timeout（如 MySQL 默认 8h，则设 7h），避免拿到已断开的连接 - 若
ConnMaxLifetime过短（如 5s），会导致连接刚建好就被回收，实际效果接近无池
没调用 db.Ping() 或忽略 db.Stats() 导致问题难定位
连接池配置是否生效、是否存在连接泄漏、空闲连接是否堆积，光看代码很难判断。运行时指标才是真相：
- 启动后务必调用
db.Ping()验证基础连通性，否则可能因 DNS、防火墙等问题静默失败 - 定期打印
db.Stats()，重点关注OpenConnections、Idle、InUse三者关系：若InUse持续高位 +Idle接近 0，说明连接不够或未及时归还 - 常见泄漏信号：
OpenConnections持续增长不回落，尤其在压测后仍不下降，大概率是rows.Close()或tx.Commit()缺失
HTTP handler 中直接 db.Query 却未控制并发量
连接池本身不解决应用层并发失控问题。即使 MaxOpenConns=100，若单个请求内并发发起 200 次查询（如循环查用户订单），仍会阻塞并触发 context deadline exceeded。
立即学习“go语言免费学习笔记（深入）”；
- 避免在 handler 内无节制地启 goroutine 调
db.Query；应先评估单请求最大连接占用数 - 对批量操作，优先用
IN或JOIN合并查询，而非 for-loop + query - 必要时加限流（如
semaphore.NewWeighted(10)）约束单请求最多占 10 个连接，防止雪崩
