高并发写库故障根因是连接池打爆、事务堆积与goroutine泄漏三重叠加；需优先排查未关闭rows、未提交/回滚事务及协程泄漏，严格按数据库max_connections的70%设SetMaxOpenConns，启用SetConnMaxLifetime防stale连接，并禁止事务内同步调用外部I/O。
高并发写库不是“吞吐量不够”的问题，而是“连接池打爆+事务堆积+goroutine泄漏”三重叠加的结果；直接加机器或调大 SetMaxOpenConns 通常会让问题更隐蔽、更难复现。
goroutine 泄漏 + 数据库连接卡死是第一排查项
很多服务在压测初期响应正常，但持续 5 分钟后 QPS 断崖下跌、pg_stat_activity 显示大量 idle in transaction 状态连接，根本原因往往是：协程没回收，事务没结束，连接被长期占用。
- 检查所有
db.Query/db.Exec调用是否配对了rows.Close()（尤其带FOR UPDATE的查询） - 确认所有
tx, err := db.Begin()后都有明确的tx.Commit()或tx.Rollback()，且放在defer里时注意 panic 捕获顺序 - 用
curl 'http://localhost:6060/debug/pprof/goroutine?debug=2'查看是否堆积大量类似database/sql.(*Tx).Commit或database/sql.rows.Next的栈帧
连接池参数必须按数据库实例能力反向设限
SetMaxOpenConns 不是越大越好，它直接对应数据库侧的连接上限。设高了会触发 PostgreSQL 的 FATAL: remaining connection slots are reserved for non-replication superuser connections，设低了又导致请求排队——关键是要匹配真实负载峰值。
-
SetMaxOpenConns建议值 = 数据库单实例最大连接数 × 0.7，例如 PostgreSQL 默认max_connections = 100，则此处设 70 是安全起点 -
SetMaxIdleConns必须设为非零值（如 10～20），否则每次写操作都新建连接，TLS 握手 + 认证开销会吃掉 30%+ RTT -
SetConnMaxLifetime(30 * time.Minute)必须启用，否则网络抖动后残留 stale connection 会持续报read tcp: i/o timeout
写密集场景必须规避事务内嵌套 HTTP/gRPC 调用
微服务写库常伴随“写完立刻通知下游”，但如果在事务中同步调用 http.Client.Do 或 grpc.ClientConn.Invoke，等于把数据库锁持有时间延长到外部服务响应完成——这会直接拖垮整个连接池。
立即学习“go语言免费学习笔记（深入）”；
- 正确做法：先
tx.Commit()，再启动新 goroutine 异步发通知，用context.WithTimeout(ctx, 5*time.Second)包裹外部调用 - 绝对禁止在事务中做日志上报、Redis 写入、消息队列 publish 等任何 I/O 操作
- 若必须强一致性，改用本地消息表 + 定时扫描，而非跨服务同步 RPC
批量写入别硬扛，优先用 COPY / INSERT ... VALUES 批量语句
单条 INSERT 在 1000 QPS 下就会让 CPU 和连接数双双飙升；而 INSERT INTO t(col1,col2) VALUES (?,?),(?,?),... 或 PostgreSQL 的 COPY 协议，吞吐能提升 5～10 倍。
- 避免循环里反复调用
db.Exec，改用sql.NamedExec或拼接多值语句（注意参数个数限制，MySQL 默认 65535，PostgreSQL 更高） - Go 标准库不支持原生
COPY，要用github.com/jackc/pgx/v5的CopyFrom方法 - 如果字段结构固定，提前编译
sql.Stmt并复用，比每次都db.Prepare快 20%+
真正卡住高并发写库的，往往不是 SQL 本身，而是连接生命周期管理、事务边界控制和 I/O 调用位置——这些细节在压力上来前几乎不暴露，一出问题就是雪崩式故障。
