应全局复用*sql.DB实例，调用sql.Open仅初始化连接池配置，通过SetMaxOpenConns和SetMaxIdleConns控制池大小，避免在handler中重复Open导致连接泄漏与性能下降。
用 database/sql 复用连接池，别手动 Open 又 Close
Go 的 database/sql 自带连接池，但很多人误以为每次查询都要 sql.Open 再 db.Close。这会导致频繁建连、端口耗尽、TLS 握手开销飙升。
-
sql.Open只是初始化驱动和连接池配置，不真正拨号；真正建连发生在第一次Query或Exec - 全局复用一个
*sql.DB实例，设置SetMaxOpenConns和SetMaxIdleConns控制池大小 - 避免在 handler 里反复
sql.Open—— 这会绕过池，还泄漏 goroutine
db, err := sql.Open("postgres", "user=app dbname=test sslmode=disable")
if err != nil {
log.Fatal(err)
}
db.SetMaxOpenConns(20)
db.SetMaxIdleConns(10)
// 后续所有查询都用这个 db，不 Close
批量插入用 INSERT ... VALUES (...), (...)，别循环 Exec
逐行 db.Exec("INSERT INTO t(x) VALUES (?)", x) 是最常见性能杀手：每条语句都走一次 round-trip、参数解析、计划缓存查找。
- PostgreSQL / MySQL 8.0+ 支持单条语句插入多行，吞吐可提升 5–20 倍
- 注意参数数量限制：MySQL 默认 max_allowed_packet 限制总 payload，PostgreSQL 对 bind 参数个数无硬限但有性能拐点
- 用
strings.Builder拼接 values，避免 fmt.Sprintf 多次内存分配
var b strings.Builder
b.WriteString("INSERT INTO users(name, email) VALUES ")
for i, u := range users {
if i > 0 {
b.WriteString(", ")
}
b.WriteString("(?, ?)")
}
_, err := db.Exec(b.String(), args...) // args 是扁平化的 []interface{}
查单行优先用 QueryRow，避免 Query + Next + Scan 手动控制
Query 返回 *sql.Rows，必须显式调用 rows.Next() 和 rows.Close()，漏掉任一环节都会导致连接卡在池中（idle but not reusable）或内存泄漏。
-
QueryRow内部自动处理单行逻辑，返回后连接立即归还池 - 即使 SQL 理论上只返回一行，也别用
Query—— 驱动无法推断意图，不会提前释放连接 - 如果真要 scan 多行，务必用
defer rows.Close()，且确保在所有 return 路径前执行
var name string
err := db.QueryRow("SELECT name FROM users WHERE id = $1", 123).Scan(&name)
if err != nil {
if err == sql.ErrNoRows {
// 处理未找到
} else {
log.Fatal(err)
}
}
WHERE 条件字段没索引？EXPLAIN 一下再上线
Go 层面优化再猛，也救不了全表扫描。很多慢查询根本原因不是 Go 代码，而是缺失索引或索引失效。
- 在 PostgreSQL 中用
EXPLAIN (ANALYZE, BUFFERS)查看实际执行计划和 I/O 开销 - 注意隐式类型转换：比如
WHERE id = '123'（id 是 int），会导致索引失效 - 复合索引顺序很重要：
WHERE a = ? AND b > ? ORDER BY c最佳索引是(a, b, c)，不是(a, c, b)
线上加索引建议用 CONCURRENTLY（PG）或 ALGORITHM=INPLACE（MySQL），避免锁表。
