本文详解 Go 中因并发查询不当导致 sql.DB 连接池耗尽并引发 goroutine 死锁的问题，通过重构数据读取逻辑、显式释放连接、合理使用 defer 和预处理语句等手段，提供安全、可扩展的数据库并发实践方案。
本文详解 go 中因并发查询不当导致 `sql.db` 连接池耗尽并引发 goroutine 死锁的问题，通过重构数据读取逻辑、显式释放连接、合理使用 `defer` 和预处理语句等手段，提供安全、可扩展的数据库并发实践方案。
在 Go 应用中，database/sql 包通过连接池管理数据库连接，默认行为是按需分配连接。但当并发逻辑设计不当时，极易触发资源死锁（Deadlock）：多个 goroutine 各自持有一个连接，却同时等待获取第二个连接才能继续执行——而所有连接均被占用，无人释放，系统彻底阻塞。
你提供的示例代码正是典型场景：
go func() {
rows, _ := db.Query("SELECT * FROM reviews LIMIT 1") // 占用 1 个连接
for rows.Next() {
db.Exec("SELECT * FROM reviews LIMIT 1") // 尝试再占 1 个连接 → 阻塞！
}
}()由于 db.SetMaxOpenConns(15) 且启动了 15 个 goroutine，每个 goroutine 在 Query() 后立即持有连接；而循环内调用的 db.Exec() 又需新连接，但池中已无空闲连接，全部 goroutine 卡在 Exec 处，形成经典循环等待型死锁。
✅ 正确解法：分阶段执行 + 显式释放连接
核心原则是：避免在同一 goroutine 中串行申请多个连接，尤其在连接池容量受限时。推荐做法是「先读取、再释放、后处理」：
go func() {
defer wg.Done()
rows, err := db.Query("SELECT * FROM reviews LIMIT 1")
if err != nil {
// 实际项目中务必处理错误
panic(err)
}
// 立即安排关闭，确保在读取完成后释放连接
defer rows.Close() // ✅ 关键：此处 defer 作用于当前函数作用域，不影响后续逻辑
var data []int
for rows.Next() {
var id int
if err := rows.Scan(&id); err != nil {
panic(err)
}
data = append(data, id)
}
// rows.Close() 在此处自动执行 → 连接归还池中
// 此时连接已释放，后续查询可复用池中资源
for _, id := range data {
_, err := db.Exec("SELECT * FROM reviews WHERE id = $1", id)
if err != nil {
panic(err)
}
}
}()⚠️ 注意：defer rows.Close() 必须放在 rows.Next() 循环之后、且在任何依赖新连接的操作之前——否则 Close() 延迟到 Exec 完成才执行，无法解除死锁。
? 进阶优化建议
-
使用 sql.Stmt 预处理语句：对重复执行的相同 SQL（尤其带参数），应提前 db.Prepare()，避免每次编译开销，并提升连接复用效率：
stmt, err := db.Prepare("SELECT * FROM reviews WHERE id = $1") if err != nil { panic(err) } defer stmt.Close() for _, id := range data { _, err := stmt.Exec(id) if err != nil { panic(err) } } -
异步触发后续操作（慎用）：若业务允许非严格顺序，可将后续查询放入新 goroutine，利用连接池动态调度：
for rows.Next() { var id int rows.Scan(&id) wg.Add(1) go func(id int) { defer wg.Done() db.Exec("SELECT * FROM reviews WHERE id = $1", id) }(id) } rows.Close() // 主连接及时释放 永远检查错误：示例中省略了错误处理仅作演示，生产代码中 Query/Scan/Exec 的返回错误必须校验，否则掩盖真实故障点。
? 总结
| 问题根源 | 解决关键 | 最佳实践 |
|---|---|---|
| 同一 goroutine 串行抢占多个连接 | 分离「读取」与「写入/二次查询」阶段 | 先 Query → Scan → Close() → 再 Exec/Query |
| defer rows.Close() 位置不当 | Close() 必须在依赖新连接前执行 | 使用 defer 于 rows.Next() 循环结束后，或封装为闭包确保时机 |
| 高频重复查询性能低 | 复用预编译语句 | db.Prepare() + stmt.Exec() 替代裸 db.Exec() |
遵循“单次连接生命周期内只执行一类操作”原则，结合连接池配置（SetMaxOpenConns/SetMaxIdleConns）与监控（如 db.Stats()），即可构建高并发、低风险的 Go 数据库应用。
