setmaxopenconns设太高反而拖慢请求，因空闲连接占用db线程/内存资源导致p99延迟飙升；应按“峰值qps×平均耗时×1.5～2”计算并≤数据库max_connections的70%，且必须与setmaxidleconns、setconnmaxidletime配对设置，事务内禁用db.query、统一使用tx对象并显式提交，持续监控db.stats()关键指标。
db.SetMaxOpenConns设太高反而拖慢请求
默认值 0（无上限）在生产环境极其危险，MySQL 或 PostgreSQL 很快报 too many connections；但设成 200 并不等于吞吐翻倍，实测反而 P99 延迟飙升。根本原因不是连接不够，而是大量空闲连接长期占用 DB 线程、内存和 TLS 握手资源。
- 推荐按「峰值 QPS × 平均查询耗时（秒）」× 1.5～2 计算，例如 QPS=300、平均耗时 40ms → 300 × 0.04 = 12，再 × 1.5 ≈ 18
- 硬上限不能超过数据库
max_connections的 70%，MySQL 通常控制在100～200，PostgreSQL 按 CPU 核数 × 20 估算 -
SetMaxOpenConns必须显式调用，别依赖默认；Go 1.12+ 若SetMaxIdleConns>SetMaxOpenConns会直接 panic
SetMaxIdleConns 和 SetConnMaxIdleTime 必须配对设
只设 SetMaxIdleConns 不设 SetConnMaxIdleTime（Go 1.15+），空闲连接会一直挂着，变成“僵尸连接”；反之只设 idle time，健康连接可能被误杀，引发重连抖动。
-
SetMaxIdleConns一般设为SetMaxOpenConns的 1/2 到 2/3（如最大 50，空闲设 25～30） -
SetConnMaxIdleTime必须小于SetConnMaxLifetime，常见设15m～20m - 云环境（K8s Pod 重启、DB 故障切换）下，两者都为
0极易导致连接泄漏或复用 stale 连接
事务内混用 db 和 tx 会饿死连接池
事务 *sql.Tx 绑定专属连接，直到 Commit() 或 Rollback() 才释放；若在事务里穿插调用 db.Query，那个连接不会归还池子，其他 goroutine 就得干等。
- 事务内所有 SQL 操作必须统一走
tx.Query/tx.Exec，禁止混用db方法 - 避免在事务中做 HTTP 请求、文件读写等耗时操作，防止连接被 hold 超过 5 秒
- 用
context.WithTimeout(ctx, 5*time.Second)包裹db.BeginTx，防止单个事务卡死整个池
不查 db.Stats() 就等于盲调参数
db.Stats() 返回的指标才是真实水位线，日志和压测数据都只是间接参考。WaitCount 和 WaitDuration 持续上涨？说明 MaxOpenConns 不够，或者查询太慢堵住了连接。
-
MaxIdleClosed高？说明MaxIdleConns设太高，或业务低峰期连接利用率极低 -
OpenConnections长期接近MaxOpenConns？要检查是否有rows没defer rows.Close()，或事务没提交/回滚 - 建议每 30 秒采集一次
db.Stats()，接入 Prometheus 监控WaitCount、Idle、InUse差值等关键指标
db.Stats() 里的数字变化，以及是否在事务边界内严格隔离 db 和 tx 的使用。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
