database/sql查询变慢主因是连接池配置不当和上下文误用：未设SetMaxOpenConns/SetMaxIdleConns致连接耗尽，用context.Background()导致请求取消后查询仍在执行；此外Scan字段顺序敏感、SELECT *引发panic与内存压力、批量操作未优化等亦为关键瓶颈。
为什么 database/sql 查询变慢了？先查连接和上下文
Go 程序数据库变慢，80% 不是 SQL 本身的问题，而是连接没管好或上下文被误用。sql.DB 是连接池，不是单个连接，它默认最大打开连接数是 0（无限制），但操作系统文件描述符和数据库服务端连接数都有上限。如果没设 SetMaxOpenConns 和 SetMaxIdleConns，高并发下容易耗尽连接、触发超时或排队等待。
另一个高频陷阱是：在 HTTP handler 中用 context.Background() 调用 QueryContext 或 ExecContext。一旦请求被客户端取消或超时，查询还在数据库里跑着——既浪费资源，又可能拖垮后续请求。
-
db.SetMaxOpenConns(20)和db.SetMaxIdleConns(10)应根据 DB 实例规格和 QPS 合理设置，生产环境别留 0 - 所有带 Context 的 DB 方法必须传入 request-scoped context（如
r.Context()），而不是context.Background() - 用
db.Stats()定期检查OpenConnections、WaitCount，突然飙升说明连接池吃紧
用 Scan 还是 struct？字段映射不匹配直接 panic
Go 的 Scan 对字段顺序极其敏感，且不校验类型兼容性；而 sqlx.StructScan 或 pgx 的 ScanStruct 虽支持 tag 映射，但字段名/类型不一致时行为不同——有的静默跳过，有的报错，有的 panic。最常见的是数据库字段是 updated_at timestamp with time zone，Go struct 字段却是 UpdatedAt string，运行时报 can't scan into dest。
- 始终用指针接收 Scan 结果：
var id int; row.Scan(&id)，否则值不会写入 - struct 字段必须是 exported（大写开头），且 tag 如
db:"updated_at"要与列名完全匹配（注意大小写、下划线） - 时间字段优先用
time.Time，避免 string → time 转换开销；若 DB 存的是 Unix timestamp 整数，用int64+ 手动转，别依赖 Scan 自动转换 - 空值处理：数据库允许 NULL 的字段，Go 中必须用
sql.NullString、sql.NullInt64等，不能直接用原生类型
SELECT * 在 Go 里比你想的更危险
表面上只是多查几个字段，实际在 Go 中会放大三类问题：内存分配、GC 压力、字段错位风险。比如表加了个新字段，Go struct 没同步更新，Scan 就会因列数不匹配直接 panic；或者某字段是 TEXT 大文本，每次查询都分配几 MB 内存，GC 频繁触发 STW。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 永远显式写出所需字段：
SELECT id, name, status FROM users WHERE ...，禁用SELECT * - 对大字段（
TEXT、JSONB、BLOB）单独查询，用SELECT id FROM users先取主键，再按需SELECT content FROM posts WHERE id = ? - 用
rows.Columns()动态检查列名和类型（调试期有用），但生产环境别依赖它做逻辑分支
批量操作别手写 for 循环，用 pgx.Batch 或 sql.Named
逐条 Exec 插入 1000 行，本质是 1000 次 round-trip，网络和解析开销远超执行本身。PostgreSQL 用户首选 pgx 的 Batch，MySQL 用户可用 sql.Named 拼接多值 INSERT（注意参数上限），或直接走 LOAD DATA（需文件权限）。
-
pgx示例：b := &pgx.Batch{}; for _, u := range users { b.Queue("INSERT INTO users(...) VALUES($1,$2)", u.Name, u.Email) }; br := conn.SendBatch(ctx, b); defer br.Close() - 原生
database/sql不支持真正的批量，INSERT INTO t VALUES (?,?),(?,?)是折中方案，但需手动拼参数，且 MySQL 默认max_allowed_packet限制单条语句大小 - 避免在事务里塞太多语句：单个事务超过 10MB 或持续 > 5s，容易锁表、拖慢 WAL 写入
真正卡住性能的，往往不是 SQL 写得不够巧，而是连接池参数拍脑袋、struct 字段漏了 sql.Null*、或者以为 SELECT * 只是“少打几个字”。这些点不改，加索引也没用。
