Go并发查数据库需对齐连接池、查询粒度与上下文控制：设MaxOpenConns≤数据库上限，用QueryRowContext+timeout防连接泄漏，批量操作优先IN而非并发goroutine。
Go 语言并发调用数据库时，**不是并发越多越快，而是连接池 + 查询粒度 + 上下文控制三者必须对齐**。盲目开 go 协程发查询，大概率触发 too many connections、context deadline exceeded 或数据库 CPU 突增，反而比串行还慢。
为什么直接起 goroutine 调用 db.QueryRow 很危险
默认 *sql.DB 的连接池大小是 0（即无限制），但实际受数据库最大连接数（如 MySQL 默认 151）、操作系统文件描述符、Go runtime 调度开销共同制约。常见表现：
- MySQL 报错：
ERROR 1040 (HY000): Too many connections - PostgreSQL 报错：
pq: sorry, too many clients already - 大量 goroutine 卡在
runtime.gopark，表现为高延迟低吞吐
根本原因：每个 db.QueryRow 都可能独占一个连接，而连接复用没被显式约束。正确做法是先设好池参数：
db.SetMaxOpenConns(20) db.SetMaxIdleConns(10) db.SetConnMaxLifetime(30 * time.Minute)
其中 MaxOpenConns 必须 ≤ 数据库侧允许的最大连接数；MaxIdleConns 建议 ≤ MaxOpenConns，避免空闲连接长期占位；ConnMaxLifetime 防止连接老化（尤其云数据库常做连接漂移）。
立即学习“go语言免费学习笔记（深入）”；
context.WithTimeout 必须套在每个查询外层
并发场景下，单个慢查询会拖垮整批请求。不加 context 控制，超时后 goroutine 仍持有连接、不释放资源，连接池迅速枯竭。
错误写法：
go func(id int) {
row := db.QueryRow("SELECT name FROM users WHERE id = ?", id)
// 没有 timeout，卡死就一直等
}(...)正确写法（带 cancel）：
go func(id int) {
ctx, cancel := context.WithTimeout(context.Background(), 500*time.Millisecond)
defer cancel()
row := db.QueryRowContext(ctx, "SELECT name FROM users WHERE id = ?", id)
// ... 处理 err == context.DeadlineExceeded
}(...)注意：QueryRowContext 是必须的；cancel() 一定要 defer，否则上下文泄漏；超时值要结合 P95 响应时间设定，不能拍脑袋填 5s。
批量操作优先用 IN 或 INSERT ... VALUES (...), (...)，别 for-range 起 goroutine
比如查 100 个用户 ID 对应的名字，起 100 个 goroutine 并发查，不如一次 SELECT name FROM users WHERE id IN (?, ?, ..., ?) —— 减少网络往返、降低锁竞争、规避连接池争抢。
适用条件：
- ID 数量可控（MySQL
max_allowed_packet通常支持几千参数） - 业务逻辑允许结果乱序（
IN不保证返回顺序） - 能接受单次查询失败则全失败（需配合重试或降级）
示例（分批 50 个一组）：
const batchSize = 50
for i := 0; i < len(ids); i += batchSize {
batch := ids[i:min(i+batchSize, len(ids))]
placeholders := strings.Repeat("?,", len(batch)-1) + "?"
rows, _ := db.QueryContext(ctx, "SELECT id, name FROM users WHERE id IN ("+placeholders+")", batch...)
// 扫描结果并映射回原顺序（需额外哈希表）
}连接池 + 并发数 + 查询复杂度必须动态匹配
没有“通用最优并发数”。同一服务在不同负载下，最佳并发值可能从 4 变到 16 —— 因为它取决于：
- SQL 是否走索引（
EXPLAIN看type和rows） - 数据库 CPU/IO 是否已饱和（
top、pg_stat_activity观察） - Go 应用自身 GC 压力（高并发触发频繁 STW）
上线前必须压测：固定 QPS 下，逐步提高 goroutine 并发数，监控 db.Stats().WaitCount（等待连接的总次数）。一旦该值非零增长，说明连接池已成为瓶颈，此时再加并发只会恶化延迟。
最易被忽略的一点：**事务内不要并发查库**。事务绑定的是单个连接，tx.QueryRowContext 在并发中若混用，会导致 sql: Transaction has already been committed or rolled back——因为底层连接被其他 goroutine 提前归还池中了。
