SetMaxOpenConns 设过高会因空闲连接占用数据库线程/内存、加剧上下文切换，导致P99延迟飙升；应按「峰值QPS×平均耗时」的1.5–2倍设置，并配合MaxIdleConns、ConnMaxLifetime等参数优化。
为什么 SetMaxOpenConns 设太高反而拖慢响应？
很多开发者看到高并发就盲目调大 SetMaxOpenConns，结果发现 P99 延迟飙升、数据库 CPU 扛不住。根本原因不是连接不够，而是连接池和数据库的协同失衡：过多空闲连接长期占用 DB 侧资源（如内存、线程、锁），尤其在 PostgreSQL 或 MySQL 中，每个连接对应一个服务端线程/进程，容易触发连接数上限或上下文切换开销。
实操建议：
-
SetMaxOpenConns值建议设为「峰值 QPS × 平均查询耗时（秒）」的 1.5–2 倍，例如 QPS=200、平均查询 50ms → 200 × 0.05 = 10，再乘 1.5 ≈ 15；不超过数据库max_connections的 70% - 务必配合
SetMaxIdleConns，通常设为与SetMaxOpenConns相同或略低（如 10–15），避免空闲连接堆积却不复用 - 启用
SetConnMaxLifetime（如 30m）和SetConnMaxIdleTime（如 5m），强制回收老化连接，防止因网络抖动或 DB 重启导致的 stale connection 报错（如"server closed the connection"）
如何识别连接池正在“假忙”？
程序日志里没报错，但接口变慢、DB 监控显示连接数稳定在高位、pg_stat_activity 或 SHOW PROCESSLIST 里大量 idle in transaction 或 sleep 状态——这是典型的“连接被借出但没归还”。常见于 defer rows.Close() 漏写、panic 后未恢复、或事务中嵌套查询未统一管控。
快速定位方法：
立即学习“go语言免费学习笔记（深入）”；
- 开启
sql.DB的日志钩子（如用github.com/leporo/sqlmock测试时打点，或生产环境 patchdriver.Conn实现计数器） - 定期调用
db.Stats()查看Idle和InUse差值是否持续为 0；若WaitCount > 0且持续增长，说明有 goroutine 在排队等连接 - 在关键路径加
context.WithTimeout，避免一个慢查询卡住整个池子；超时后连接会被自动标记为坏并关闭
使用 database/sql 时哪些写法会隐式阻塞连接？
Go 的 database/sql 是懒加载 + 连接复用模型，但部分操作不显式释放连接，导致它一直被占着。最典型的是忘记处理 *sql.Rows。
必须注意：
-
rows, err := db.Query(...)后，即使rows.Next()返回false，也必须调用rows.Close()；否则连接不会归还到池中 -
db.QueryRow().Scan()是安全的，内部会自动 close；但db.QueryRowContext(ctx).Scan()同理，前提是 ctx 不提前 cancel 导致 scan 失败而跳过清理逻辑 - 事务内执行多个查询时，不要混用
tx.Query和db.Query；后者绕过事务，还可能从另一个连接池取连接，造成事务语义失效
要不要换 pgx 或 sqlx？
sqlx 只是 database/sql 的语法糖封装，不改变连接池行为，性能无提升；而 pgx（v4+）自带独立连接池实现，支持 pipeline、binary protocol、连接健康检查，对 PostgreSQL 场景确实能降低 10%–20% 的 p95 延迟，尤其在高吞吐小查询场景。
但迁移成本需权衡：
- 如果已用 MySQL 或 TiDB，
pgx不适用；改用go-sql-driver/mysql的最新版（v1.7+）并开启multiStatements=false和interpolateParams=true更实际 -
pgxpool的默认配置比sql.DB更激进（如MinConns=10），上线前必须压测验证 idle 连接数是否超出 DB 承载能力 - 所有
Scan必须用pgx.Row/pgx.Rows，不能混用sql.Row，否则 panic
