不能直接用 BenchmarkXxx 测数据库操作，因连接建立、驱动初始化等干扰会导致结果失真；必须外部初始化 sql.DB、预热连接池、复用 Stmt、显式设置连接池参数，并仅将 SQL 执行放入 b.N 循环。
Go 的 database/sql 包本身不提供 Benchmark 支持，性能测试必须靠自己构造可复现的压测逻辑——直接用 go test -bench 跑数据库操作会因连接建立、事务开销、SQL 编译等干扰项导致结果失真。
为什么不能直接写 BenchmarkXxx 函数跑 db.Query
标准 go test -bench 会在短时间内反复调用 Benchmark 函数，而每次调用若都新建连接、执行 SQL、关闭资源，测的就不是“查询本身”，而是“连接池初始化 + 网络往返 + 驱动解析”的混合耗时。更严重的是，多数数据库驱动（如 lib/pq、mysql/mysql-driver）在首次调用时有隐式初始化行为，会导致前几次迭代极慢，后续突然变快，benchmem 统计也会不准。
实操建议：
- 所有
sql.DB实例必须在BenchmarkXxx外部初始化（例如TestMain或全局变量），避免每次迭代重建连接池 - 预热连接池：在 Benchmark 开始前，用
db.Ping()+ 若干次 dummy 查询触发连接建立和语句预编译 - 禁止在 Benchmark 循环体内调用
db.Close()，否则连接池被清空，后续迭代全走新连接路径 - 使用
db.Prepare复用*sql.Stmt，避免每次迭代重复解析 SQL（尤其对 PostgreSQL / MySQL 的参数化查询）
sql.DB.SetMaxOpenConns 和 SetMaxIdleConns 怎么设才反映真实负载
默认值（0 表示无限制）会让压测结果严重偏离生产环境——你测的是“无限并发下驱动能扛多少”，而不是“服务配置了 max_open=20 时单次查询均值”。必须按目标部署场景显式设置。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
-
db.SetMaxOpenConns(20)模拟典型 Web 服务连接池上限 -
db.SetMaxIdleConns(20)避免频繁建连/销毁，让连接真正复用 - 若测试高并发短连接场景（如 CLI 工具），可设
MaxOpenConns=100+MaxIdleConns=0，但需在注释中明确标注该模式 - 用
db.Stats()在 Benchmark 前后打印OpenConnections、WaitCount，确认是否出现连接等待（WaitCount > 0表示连接池瓶颈）
如何写出稳定、可比的 Benchmark 函数
核心原则：只让「执行 SQL」这一动作进入 b.N 循环，其余全部前置。同时要隔离事务、错误处理、结果扫描等变量。
func BenchmarkQueryUserByID(b *testing.B) {
db, _ := sql.Open("pgx", "user=dev dbname=test")
db.SetMaxOpenConns(20)
db.SetMaxIdleConns(20)
defer db.Close()
// 预热
db.Ping()
_, _ = db.Exec("SELECT 1")
// 复用 Stmt
stmt, _ := db.Prepare("SELECT id, name FROM users WHERE id = $1")
defer stmt.Close()
b.ResetTimer() // 关键：重置计时器，跳过准备阶段
for i := 0; i < b.N; i++ {
var id int
var name string
err := stmt.QueryRow(i%1000 + 1).Scan(&id, &name)
if err != nil && err != sql.ErrNoRows {
b.Fatal(err)
}
}
}
注意点：
-
b.ResetTimer()必须在预热完成后、循环开始前调用，否则包含 Prepare/Ping 耗时 - 用
i % 1000 + 1控制 ID 范围，避免查不到数据导致大量sql.ErrNoRows干扰 - 不忽略
err，但只 fatal 真正异常（ErrNoRows是业务正常路径） - 避免在循环里做字符串拼接、JSON 序列化等非 DB 操作，否则 benchmark 测的是 Go 运行时而非数据库延迟
容易被忽略的底层影响：驱动选择与上下文取消
同一个 SELECT，用 lib/pq 和 jackc/pgx 基准结果可能差 30%+；而没传 context.Context 的调用，在超时时会卡死整个 goroutine，导致 b.N 实际执行次数远低于预期。
实操建议：
- 性能敏感场景优先用
pgx/v4（PostgreSQL）或go-sql-driver/mysql（MySQL），它们比lib/pq少一层 interface 抽象 - 所有
Query/Exec必须带context.WithTimeout，例如stmt.QueryRowContext(ctx, id)，否则网络抖动会拖垮整个 benchmark - 用
go test -benchmem -benchtime=10s延长测试时间，减少 GC 噪声影响 - 对比不同驱动时，确保连接字符串参数一致（如
sslmode=disable、binary_parameters=yes）
真正的瓶颈往往不在 SQL 本身，而在连接池配置是否匹配压测模型、Stmt 是否复用、上下文是否可控——这些细节不拉平，Benchmark 数据之间根本不可比。
