17370845950

应避免循环中执行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 内部已对简单查询做轻量缓存，没必要为低频语句提前准备。

• 适用场景：每秒执行 >10 次、结构完全固定的查询，例如 "UPDATE accounts SET balance = balance + ? WHERE id = ?"
• 务必调用 stmt.Close()，否则 Stmt 对象不会被 GC，且底层连接可能无法释放
• 不要在 HTTP handler 里每次 Prepare —— 提前在 init() 或服务启动时完成，并复用全局变量或依赖注入

真正卡住性能的往往不是单条 SQL 写得多炫，而是连接没管好、上下文没传进、错误被静默吞掉。尤其注意 ConnMaxLifetime 和 QueryRowContext 的 err 检查，这两个点在线上最容易突然爆发问题。