因为基准测试会重复执行函数体，若初始化操作（如建表、插入数据）未与查询逻辑分离，其耗时会被计入结果导致失真；应将准备动作放在b.ResetTimer()前，之后仅保留待测的db.Query等操作。
为什么 Benchmark 函数里不能直接用 db.Query 而要加 b.ResetTimer()
因为 Go 的基准测试会反复执行函数体，如果在初始化连接、建表、插入测试数据的代码没和实际查询逻辑区分开，这些耗时会被计入结果，导致 ns/op 失真。比如你每次 BenchmarkSelectUser 都重新 db.Exec("INSERT ...")，那测的其实是「插入+查询」，不是纯查询。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 所有准备动作（开连接、建表、预热数据）写在
Benchmark函数开头，且必须在b.ResetTimer()之前完成 -
b.ResetTimer()后只保留真正要测的数据库操作，例如db.QueryRow("SELECT name FROM users WHERE id = ?", 1) - 若需多次查询，用
for i := 0; i 包裹，让 Go 自动控制迭代次数
如何避免连接池干扰导致的 Benchmark 结果波动
默认 sql.DB 的连接池大小是 0（即无限制），但在压测中可能瞬间拉起大量连接，触发系统资源竞争或数据库端限流；而设得太小又会让并发请求排队，测出的是锁等待而非 SQL 本身性能。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 显式设置连接池参数：
db.SetMaxOpenConns(10)、db.SetMaxIdleConns(5)，数值按目标并发量设定（如go test -bench=. -benchtime=5s -benchmem下观察b.N实际值） - 在
Benchmark开始前调用db.Ping()确保连接可用，防止首次查询因建连延迟拉高均值 - 避免在多个
Benchmark函数间复用同一个*sql.DB实例——不同测试可能有不同连接池配置，互相污染
使用 sqlmock 做 Benchmark 是否有意义
没有意义。sqlmock 是为单元测试设计的，它拦截 database/sql 调用并返回预设响应，不走真实网络、不解析 SQL、不触发引擎执行计划。它的 Query 耗时恒定在几十纳秒级，完全无法反映真实数据库查询的 I/O、锁、索引扫描等开销。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 性能评估必须连接真实数据库实例（哪怕本地
docker run --rm -e POSTGRES_PASSWORD=pass -p 5432:5432 postgres） - 如需隔离环境，用
testcontainers-go启停临时容器，配合defer cleanup()保证每次 Benchmark 干净启动 - 若仅验证 Query 语句拼接逻辑是否正确，用 sqlmock 单元测试；但只要提到了“性能”，就必须绕过 mock
如何让 Benchmark 输出包含内存分配统计（-benchmem）且结果可信
Go 的 -benchmem 会报告每次操作的堆内存分配次数和字节数，但若查询结果未被读取或扫描，驱动可能延迟分配，导致统计偏低；反之，若反复扫描同一行而不释放，又可能掩盖真实 GC 压力。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 必须完整消费结果集：对
*sql.Rows调用rows.Next()+rows.Scan()，或对*sql.Row调用row.Scan()，否则驱动可能跳过内存分配路径 - 避免在循环内声明大结构体变量（如
var u User），改用指针传参或复用变量，减少每次迭代的 alloc 次数 - 注意驱动差异：pq（PostgreSQL）和 mysql（Go-MySQL-Driver）对
time.Time、JSON字段的解码开销不同，Benchmark 应固定驱动版本并注明
b.ResetTimer() 或复用连接池，比选错 ORM 更容易得出错误结论。 
