如何在Golang中进行数据库查询性能测试_Golang sql查询Benchmark实践

必须在Benchmark外初始化*sql.DB并复用,禁止单次新建;设MaxOpen/IdleConns为1,预热连接,显式Scan优于反射解包,确保索引命中,验证执行计划,关闭rows避免内存泄漏和统计失真。

testing.B 跑 SQL 查询基准测试,必须控制连接复用

直接在 BenchmarkXxx 函数里每次新建 *sql.DB 会严重污染结果——连接建立、认证、TLS 握手全被算进耗时。真实场景中 *sql.DB 是长生命周期对象,测试必须模拟这点。

  • BenchmarkXxx 外部初始化一次 *sql.DB,用全局变量或 testMain 管理生命周期
  • 调用 db.SetMaxOpenConns(1)db.SetMaxIdleConns(1) 避免连接池干扰单次查询测量
  • 每次循环前执行 db.Exec("SELECT 1") 确保连接已就绪(防首次查询的冷启动延迟)

Rows.Scan 方式影响显著,别默认用 struct 反射解包

sqlx.StructScanmap[string]interface{} 解析 100 行数据,比手动 rows.Scan(&id, &name, &age) 慢 3–5 倍。反射和类型检查在循环内反复发生,testing.B.N 越大,差距越明显。

  • 性能敏感场景,优先写显式 Scan,尤其字段数固定、类型明确时
  • 若必须用 struct,确保字段有 db tag 且类型严格匹配(int64BIGINTstringVARCHAR),避免运行时类型转换
  • 避免在 Benchmark 循环内 new struct 实例——提前分配好指针切片复用内存

WHERE 条件是否走索引,会彻底改变 db.Query 的 Benchmark 结果

同一张表、同样代码,WHERE id = ?(主键查询)和 WHERE created_at > ?(无索引时间范围)的 p99 耗时可能差两个数量级。Benchmark 不是测 Go 代码,是在测“SQL + 执行计划 + 数据库负载”的组合表现。

  • 测试前务必用 EXPLAIN 确认执行计划,把 type=ALL(全表扫描)换成 type=consttype=range
  • db.QueryRow("SELECT COUNT(*) FROM ...") 先确认测试数据量级(比如 100 行 vs 100 万行)
  • 避免在测试期间其他进程访问同库同表,MySQL 的 innodb_row_lock_waits 上升会直接拉高延迟

别忽略 rows.Close(),漏掉它会导致 Benchmark 内存持续增长

rows 是资源句柄,不显式 Close() 不仅可能触发连接泄漏,还会让 testing.B 的内存统计失真(GC 不及时回收底层 network buffer)。Go 1.22+ 的 rows 虽支持 defer,但在 Benchmark 循环里 defer 本身有开销。

立即学习“go语言免费学习笔记(深入)”;

  • 统一写成 defer rows.Close() 放在 rows, err := db.Query(...) 后立即执行
  • 如果用 QueryRow,不用 Close,但要注意它内部仍可能持有连接,高并发下建议搭配 db.SetConnMaxLifetime
  • 运行 go test -bench=. -benchmem 时重点看 Benchmem 输出的 allocs/op —— 理想值应接近 0(仅 SQL 字符串和参数分配)
func BenchmarkUserSelectByID(b *testing.B) {
	db := setupTestDB() // 外部初始化,非 b.Helper()
	defer db.Close()

	b.ResetTimer()
	for i := 0; i < b.N; i++ {
		rows, err := db.Query("SELECT id, name, email FROM users WHERE id = $1", i%1000)
		if err != nil {
			b.Fatal(err)
		}
		defer rows.Close() // 必须放这里

		for rows.Next() {
			var id int
			var name, email string
			if err := rows.Scan(&id, &name, &email); err != nil {
				b.Fatal(err)
			}
			// 不做业务逻辑,避免干扰计时
		}
	}
}
实际压测时,数据库连接数、查询缓存开关、甚至 pg_stat_statements 是否启用,都会让数字漂移。与其追求绝对数值,不如固定环境后对比不同 Scan 方式或不同索引策略的相对变化。