SetMaxOpenConns不能设太高，否则会超出数据库连接上限导致拒绝连接或goroutine阻塞；应按DB承载能力、事务耗时反推合理值，并监控WaitCount和OpenConnections。
Go sql.DB 的 SetMaxOpenConns 为什么不能设太高
高并发下盲目调大 SetMaxOpenConns 不仅不会提升吞吐，反而可能压垮数据库或触发连接拒绝。MySQL 默认最大连接数通常是 151，PostgreSQL 是 100（由 max_connections 控制），超出后新连接会直接报错 ERROR: sorry, too many clients already 或 MySQL 的 Too many connections。
实际应按数据库承载能力、单连接平均 QPS、事务持续时间反推合理值。例如：DB 能扛 200 连接，应用平均事务耗时 50ms，则理论每秒最多处理 200 / 0.05 = 4000 请求；若你设 MaxOpenConns=1000，但 DB 只能分给这个应用 80 连接，剩下 920 个永远卡在等待队列里，sql.DB 的 Wait 会阻塞 goroutine，拖慢整体响应。
-
SetMaxOpenConns建议初始值设为数据库分配给该服务的连接上限 × 0.7～0.8（留缓冲） - 线上务必监控
sql.DB.Stats().OpenConnections，长期接近MaxOpenConns就要告警 - 避免设为 0（不限制）——这是生产环境常见误配，等同于放弃连接数兜底
SetMaxIdleConns 和 SetConnMaxIdleTime 怎么配合用
SetMaxIdleConns 控制空闲连接池大小，SetConnMaxIdleTime 决定空闲连接存活多久。二者不联动，必须一起调优，否则会出现“池子里全是过期连接”或“频繁新建/销毁连接”。
典型问题：只设 MaxIdleConns=20，但没设 ConnMaxIdleTime，DBA 在后台重启了数据库，所有 idle 连接变成僵尸连接，下次复用时直接报 driver: bad connection；反之，设了很短的 ConnMaxIdleTime（如 1s），但 MaxIdleConns 很小（如 2），会导致每次请求都大概率新建连接，失去连接复用意义。
立即学习“go语言免费学习笔记（深入）”；
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
SetMaxIdleConns通常设为SetMaxOpenConns的 1/2～2/3（例如 Open=100 → Idle=50） -
SetConnMaxIdleTime推荐 30m～1h（30 * time.Minute），需略小于数据库端的wait_timeout（MySQL 默认 8h，但中间件/代理常缩到 1h） - PostgreSQL 用户额外注意：
pgx驱动默认启用连接健康检查，而标准database/sql+lib/pq不检查，建议搭配SetConnMaxLifetime使用
SetConnMaxLifetime 是防什么的，值设多少合适
SetConnMaxLifetime 强制连接在创建后最多存活多久，到期后被自动关闭并从池中移除。它不是用来解决连接泄漏的，而是应对数据库侧的连接老化策略（比如 MySQL 的 wait_timeout、云厂商 RDS 的连接空闲回收、K8s Service DNS 变更导致后端 IP 更新等）。
如果这个值设得太长（比如 24h），而数据库实际 1h 就断开空闲连接，那么你的应用会拿到大量“逻辑存活但物理已断”的连接，执行 SQL 时抛 read: connection reset by peer 或 broken pipe；设得太短（比如 10s），则连接刚建好就销毁，完全无法复用。
- 安全做法：设为数据库
wait_timeout的 60%～80%，例如 MySQLwait_timeout=3600（1h），这里设2 * time.Hour就偏高，应设45 * time.Minute - 云数据库（如阿里云 PolarDB、AWS RDS）务必查文档确认其连接空闲超时值，通常比自建更激进（有 5～15 分钟限制）
- 该参数对短生命周期服务（如 AWS Lambda）意义不大，但对常驻进程（HTTP server、worker）是刚需
如何验证连接池参数是否生效且无异常
光设参数不验证，等于没调。Go 的 sql.DB 提供 Stats() 方法暴露实时状态，但很多人只看 OpenConnections，忽略 Idle、WaitCount、MaxOpenConnections 等关键字段。
常见误判：看到 OpenConnections 常年稳定在 20，就认为“池子够用”，其实可能 WaitCount 每分钟涨几百次，说明大量请求在排队等连接，只是没超时而已。
- 每 10 秒打一次日志：
stats := db.Stats() log.Printf("db stats: open=%d idle=%d waitCount=%d maxOpen=%d", stats.OpenConnections, stats.Idle, stats.WaitCount, stats.MaxOpenConnections) - 关注
WaitCount是否持续上涨，上涨说明MaxOpenConns不足或慢查询堵住连接 - 观察
Idle是否长期为 0，如果是，说明连接几乎没被复用，可能MaxIdleConns太小，或事务/查询太长 - 用 pprof 查
/debug/pprof/goroutine?debug=1，搜database/sql.(*DB).conn，看是否有大量 goroutine 卡在semacquire—— 这是连接池等待的明确信号
连接池不是设完就高枕无忧的模块。真正难的是把 MaxOpenConns、MaxIdleConns、ConnMaxIdleTime、ConnMaxLifetime 四个参数和数据库实际行为对齐，而数据库的行为又受版本、部署方式、中间件、网络环境共同影响。线上出问题时，第一反应不该是“加大连接数”，而是先看 Stats() 里的 WaitCount 和 Idle。
