必须在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.StructScan 或 map[string]interface{} 解析 100 行数据，比手动 rows.Scan(&id, &name, &age) 慢 3–5 倍。反射和类型检查在循环内反复发生，testing.B.N 越大，差距越明显。

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

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

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

• 测试前务必用 EXPLAIN 确认执行计划，把 type=ALL（全表扫描）换成 type=const 或 type=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)
			}
			// 不做业务逻辑，避免干扰计时
		}
	}
}