database/sql 的 queryrow 和 query 默认不支持并发，因为 sql.rows 和 sql.row 实例不可跨 goroutine 复用，其内部游标和缓冲区状态要求 scan 顺序执行；并发调用会触发 panic。
为什么 database/sql 的 QueryRow 和 Query 默认不支持并发？
Go 标准库的 database/sql 包本身是并发安全的，但单个 *sql.Rows 或 *sql.Row 实例**不能跨 goroutine 复用**。常见错误是启动多个 goroutine 同时调用 rows.Scan，导致 panic："sql: Rows are not safe for concurrent use"。
根本原因在于 *sql.Rows 内部维护游标状态和缓冲区，Scan 是顺序推进操作；并发读会破坏一致性。
- 正确做法：每个 goroutine 应该独立执行
db.Query或db.QueryRow，拿到自己的*sql.Rows或*sql.Row - 不要在 goroutine 间传递
*sql.Rows，也不要复用已 Close 的 rows - 务必在 goroutine 内调用
rows.Close()，否则连接不会归还连接池
如何用 sync.WaitGroup + db.Query 安全并发查多张表或同表不同条件？
典型场景：并行查询用户基本信息、订单统计、积分余额三个接口数据，再聚合返回。这时应为每个子查询启动独立 goroutine，并发发起 SQL 请求。
var wg sync.WaitGroup
var mu sync.Mutex
results := make(map[string]interface{})
<p>wg.Add(3)
go func() {
defer wg.Done()
row := db.QueryRow("SELECT name FROM users WHERE id = ?", 123)
var name string
if err := row.Scan(&name); err == nil {
mu.Lock()
results["name"] = name
mu.Unlock()
}
}()
go func() {
defer wg.Done()
rows, _ := db.Query("SELECT COUNT(*) FROM orders WHERE user_id = ?", 123)
// ... scan logic
}()
go func() {
defer wg.Done()
// ...
}()</p><p>wg.Wait()
- 每个 goroutine 调用独立的
db.Query/db.QueryRow，不共享结果集 - 用
sync.Mutex保护共享 map 写入（或改用sync.Map） - 注意：
db对象本身是并发安全的，可被所有 goroutine 共享
什么时候该用 context.WithTimeout 控制并发查询？
并发查多个依赖时，一个慢查询拖垮整体响应时间很常见。比如三个子查询中有一个因索引缺失卡住 5 秒，而业务 SLA 要求 800ms 内返回。
立即学习“go语言免费学习笔记（深入）”；
- 必须给每个
db.QueryRow/db.Query传入带超时的context.Context - 避免使用全局无 timeout 的
context.Background() - 超时后，对应 goroutine 会提前退出，但底层连接可能仍在等待 DB 响应 —— 这正是
context的作用：通知 driver 中断等待
示例：
ctx, cancel := context.WithTimeout(context.Background(), 300*time.Millisecond)
defer cancel()
row := db.QueryRowContext(ctx, "SELECT ...", args...)
err := row.Scan(&v)
if errors.Is(err, context.DeadlineExceeded) {
// 记录超时，返回默认值或降级数据
}
连接池配置不当是并发性能瓶颈的真正元凶
很多人优化 SQL、加索引、改结构，却忽略 db.SetMaxOpenConns 和 db.SetMaxIdleConns。并发高时若连接池太小，goroutine 会在 db.Query 处排队等待空闲连接，表现像“查询变慢”，实则是阻塞在获取连接上。
-
db.SetMaxOpenConns(20)：最大同时打开连接数，建议设为 QPS × 平均查询耗时（秒），例如 100 QPS × 0.2s = 20 -
db.SetMaxIdleConns(20)：空闲连接上限，避免连接闲置过多占用 DB 资源；一般与MaxOpenConns相同或略低 -
db.SetConnMaxLifetime(30 * time.Minute)：强制回收长连接，防止 MySQL 的wait_timeoutkill 掉空闲连接导致下一次 Query 报invalid connection
没调过这些参数就谈“Go 并发查数据库快”，大概率是在裸奔。
