必须在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，确保字段有
dbtag 且类型严格匹配（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)
}
// 不做业务逻辑，避免干扰计时
}
}
}
实际压测时，数据库连接数、查询缓存开关、甚至 pg_stat_statements 是否启用，都会让数字漂移。与其追求绝对数值，不如固定环境后对比不同 Scan 方式或不同索引策略的相对变化。 
