go sql.db连接池默认参数保守，高并发下易卡顿，需合理设置setmaxopenconns、setmaxidleconns和setconnmaxlifetime，并通过db.stats()监控waitcount、waitduration等真实指标优化。
Go sql.DB 连接池默认参数太保守，高并发下会卡住
Go 的 sql.DB 默认只允许最多 2 个空闲连接、最大 0 个连接（即不限制上限但初始极低），实际跑 Web 服务时，请求一多就卡在 db.Query 或 db.Exec 上，日志里看不到报错，只是响应变慢甚至超时。
必须手动调大两个关键参数：SetMaxOpenConns 和 SetMaxIdleConns。前者控制最大可建立的连接数（含忙/闲），后者控制空闲时保留在池里的连接数。两者不是越大越好——设太高会压垮数据库；设太低则频繁建连销毁，CPU 和延迟双升。
-
SetMaxOpenConns建议设为数据库侧允许的最大连接数的 70%～80%，比如 PostgreSQLmax_connections = 100，这里设80比较稳妥 -
SetMaxIdleConns推荐等于SetMaxOpenConns，避免每次请求都新建连接；若 DB 实例内存吃紧，可略低（如设为50） - 别忘了
SetConnMaxLifetime（如30 * time.Minute），防止连接因网络中间件（如 RDS Proxy、HAProxy）静默断连后还被复用
用 DBStats 看真实连接行为，而不是猜
光设参数没用，得看 db.Stats() 返回的 sql.DBStats 结构体——它反映的是运行时真实状态，不是配置值。常见误判是看到 Idle 数很低，就以为连接池不够，其实可能是 WaitCount 高（说明有 goroutine 在等连接），或 MaxOpenConnections 被设成了 0（Go 1.19+ 默认值已改，但老项目可能还沿用旧逻辑）。
- 重点关注
WaitCount和WaitDuration：非零说明连接池已满，请求在排队；持续增长就得调大SetMaxOpenConns -
OpenConnections长期接近MaxOpenConnections，且Idle接近 0，说明连接几乎全在忙，要考虑优化 SQL 或加缓存 - 定期打日志（比如每 30 秒）：
log.Printf("db stats: %+v", db.Stats())，别只在启动时看一眼
PostgreSQL 与 MySQL 的连接池表现差异不能忽略
MySQL 驱动（go-sql-driver/mysql）对连接失效更敏感，空闲连接容易被服务端主动 kill（尤其在 wait_timeout 较短时），所以 SetConnMaxLifetime 必须显式设置，且建议比 DB 的 wait_timeout 少 1～2 分钟；PostgreSQL 驱动（lib/pq 或 jackc/pgx）相对耐久，但若用了 RDS Proxy 或 PgBouncer，中间层的连接复用策略会让 DBStats 中的 OpenConnections 显得“虚高”——它统计的是到 Proxy 的连接，不是到 PG 后端的真实连接数。
立即学习“go语言免费学习笔记（深入）”；
- MySQL 场景下，务必加
timeout=30s&readTimeout=30s&writeTimeout=30s到 DSN，否则单个坏连接会拖垮整个池 - PgBouncer +
pgx时，把SetMaxOpenConns设得比后端 PG 的max_connections还高也没用，瓶颈在 PgBouncer 的max_client_conn和default_pool_size - 驱动升级要小心：
pgx/v4的stdlib包和pgx/v5的stdlib对SetMaxIdleConns行为略有不同，v5 更严格遵循设置值
健康检查里查 db.Ping 不代表连接池健康
db.Ping 只是拿一个连接执行 PING（或 SELECT 1），成功了只说明此刻至少有一个可用连接，完全掩盖了池子是否长期饥饿、是否有大量连接卡在 WaitDuration 里。K8s 的 liveness probe 如果只靠 db.Ping，可能服务早卡死，探针还在回 200。
- 真正的健康检查应组合判断：
db.Ping+db.Stats().WaitCount是否突增 +db.Stats().OpenConnections是否长时间饱和 - 避免在 HTTP handler 里直接调
db.Ping，它会阻塞；改用异步 ticker 定期采集并缓存DBStats，接口只读缓存 - 如果用的是
pgxpool（非sql.DB），它的Stat()方法字段名不同（如AcquireCount替代WaitCount），别套用sql.DBStats的解读逻辑
事情说清了就结束
