应避免循环中执行db.Query/db.Exec，优先批量操作；合理配置连接池参数；必须使用QueryRowContext并检查err；高频固定查询可预编译Stmt。
避免在循环里执行 db.Query 或 db.Exec
这是最常见也最伤性能的写法：每次循环都开新连接、发新请求、解析结果。即使用了连接池，网络往返和 SQL 解析开销也会指数级放大。
- 批量操作优先用
INSERT INTO ... VALUES (...), (...), (...)而非多次单条INSERT - 查询多条记录时，用
IN子句 + 参数化（注意参数数量限制，PostgreSQL 默认 65535，MySQL 约 1000–2000） - 实在要循环查，先收集 ID 列表，再一次性
SELECT * FROM users WHERE id IN (?)，用sqlx.In或手动拼接（确保 ID 已校验为整型/UUID）
正确使用 database/sql 的连接池配置
默认连接池太保守：MaxOpenConns=0（不限制）、MaxIdleConns=2、ConnMaxLifetime=0。高并发下容易卡在等待空闲连接上，或复用过期连接导致 connection refused / i/o timeout。
- 显式设置
db.SetMaxOpenConns(20)和db.SetMaxIdleConns(10)，数值按压测调整（通常MaxOpenConns ≈ QPS × 平均查询耗时（秒）） - 必须设
db.SetConnMaxLifetime(5 * time.Minute)，防止数据库侧主动断连后 Go 还往里塞请求 - 加
db.SetConnMaxIdleTime(30 * time.Second)，及时清理长时间空闲连接
用 QueryRowContext 替代 QueryRow，并始终检查 err
QueryRow 不支持超时控制，一旦数据库卡住，goroutine 就永久阻塞。更隐蔽的问题是：很多人只检查 Scan 错误，忽略 QueryRow 本身的错误（比如语法错、表不存在），导致返回零值却无报错。
- 永远用带 context 的版本：
row := db.QueryRowContext(ctx, "SELECT name FROM users WHERE id = ?", userID) if err := row.Scan(&name); err != nil { if errors.Is(err, sql.ErrNoRows) { // 处理未找到 } else { // 处理其他错误 } } - 不要省略
ctx：HTTP handler 中用r.Context()，定时任务中用context.WithTimeout(context.Background(), 3*time.Second) -
QueryRowContext返回的err必须检查——它可能包含连接失败、上下文取消、SQL 编译失败等关键信息
预编译语句（sql.Stmt）适合高频固定查询
对反复执行的 SQL（如用户登录校验、订单状态更新），用 db.Prepare 可跳过服务端 SQL 解析与计划生成，降低延迟。但滥用反而有害：Stmt 是连接绑定的，长期持有会占用连接资源；且 Go 的 database/sql 内部已对简单查询做轻量缓存，没必要为低频语句提前准备。
立即学习“go语言免费学习笔记（深入）”；
- 适用场景：每秒执行 >10 次、结构完全固定的查询，例如
"UPDATE accounts SET balance = balance + ? WHERE id = ?" - 务必调用
stmt.Close()，否则 Stmt 对象不会被 GC，且底层连接可能无法释放 - 不要在 HTTP handler 里每次
Prepare—— 提前在init()或服务启动时完成，并复用全局变量或依赖注入
真正卡住性能的往往不是单条 SQL 写得多炫，而是连接没管好、上下文没传进、错误被静默吞掉。尤其注意 ConnMaxLifetime 和 QueryRowContext 的 err 检查，这两个点在线上最容易突然爆发问题。
