Go 数据库查询优化：慢 SQL、连接池与事务排查

数据库慢经常被误判为连接池问题。连接池等待只是现象，根因可能是索引缺失、扫描行数过多、事务持锁或查询返回过大。Go 服务优化 SQL，要把数据库执行和应用连接池放在一张图里看。

先看 SQL 计划

EXPLAIN 或 EXPLAIN ANALYZE 能告诉你是否走索引、扫描多少行、是否排序和临时表。没有查询计划，只调 Go 代码很难解决数据库瓶颈。

DBStats 是排队信号

WaitCount 和 WaitDuration 增长说明应用在等连接，但不一定说明连接数太小。可能是慢 SQL 占住连接太久。

事务越短越好

事务持有连接和锁。把网络请求、复杂计算和大对象序列化放进事务，会把并发问题放大到整个数据库。

生产场景

适用于接口慢点集中在查询、连接池等待增长或数据库 CPU/锁等待上升的场景。

关键指标

• 慢 SQL 耗时和扫描行数
• DBStats WaitDuration
• 事务耗时、锁等待和返回行数

常见误区

• 看到 WaitCount 就盲目加连接数
• 忽略事务里的非 SQL 操作
• 只优化应用不看执行计划

代码示例

stats := db.Stats()
log.Printf("wait=%d wait_duration=%s", stats.WaitCount, stats.WaitDuration)
// SQL 层同时看 EXPLAIN 和慢查询日志

上线检查

• 优化前后必须保留同一条件下的 benchmark 或 profile。
• 至少观察 P95/P99、错误率、CPU、内存和 GC 指标。
• 如果改动影响热路径，必须准备灰度和回滚方案。