Go 语言并发数据库操作需合理配置连接池、明确事务边界、避免长事务和连接泄漏；必须显式设置 SetMaxOpenConns、SetMaxIdleConns 等参数，事务须单 goroutine 执行并显式提交或回滚，只读用连接池、强一致写用事务、跨服务用最终一致性。
Go 语言通过 database/sql 包原生支持并发数据库操作，但默认连接池和事务行为若不加控制，容易引发连接耗尽、死锁或数据不一致。关键不在“开多个 goroutine”，而在合理配置连接池、明确事务边界、避免长事务和连接泄漏。
合理配置数据库连接池
默认连接池（最大连接数 
0，即无限制；空闲连接数 2）在高并发下极易打垮数据库。必须显式调优：
- SetMaxOpenConns：设为略高于峰值并发请求数（如 50–100），防止创建过多连接导致数据库拒绝服务
-
SetMaxIdleConns：建议与
MaxOpenConns相同或略低（如 50），减少连接反复建立/销毁开销 -
SetConnMaxLifetime：设为 3–5 分钟（如
3 * time.Minute），强制复用老连接前重连，规避网络中断或数据库连接超时问题 -
SetConnMaxIdleTime：设为 1–3 分钟（如
1 * time.Minute），及时清理长期空闲连接，释放数据库资源
事务必须显式控制生命周期
事务不是并发安全的，*sql.Tx 对象不能被多个 goroutine 同时使用。常见错误是把 tx 传入多个协程执行不同语句——这会 panic 或行为未定义。
- 每个事务逻辑应封装在一个函数内，在单个 goroutine 中完成所有
tx.Query/Exec操作 - 务必调用
tx.Commit()或tx.Rollback()，建议用defer tx.Rollback()开头，再在成功时显式tx.Commit()覆盖 - 避免在事务中做 HTTP 请求、文件读写等耗时操作，否则会长时间占用连接，拖垮整个池
按场景选择连接方式：连接池 vs 显式事务 vs 无事务
不是所有操作都需要事务，也不是所有并发都该共用一个连接池：
-
只读查询（如列表页、详情页）：直接用
db.Query/QueryRow，走连接池，无需事务 -
强一致性写入（如扣库存+记日志）：用
db.BeginTx创建事务，全程用该tx对象操作，结束后立即提交或回滚 - 跨库/跨服务操作：Go 层不实现分布式事务，改用最终一致性（如发消息 + 本地事务 + 定时对账）
监控与排查连接问题
连接异常往往表现为超时、"too many connections" 或 goroutine 堆积。可通过以下方式定位：
- 定期调用
db.Stats()获取OpenConnections、InUse、Idle等指标，暴露到 Prometheus - 开启
sql.Open后的db.SetConnMaxLifetime和SetConnMaxIdleTime并配合理日志，确认连接是否及时回收 - 使用
pprof查看 goroutine 堆栈，若大量卡在db.Query或tx.Commit，说明连接池瓶颈或事务未关闭
不复杂但容易忽略：事务对象不可复用、连接池参数不设等于裸奔、长时间运行的事务是并发杀手。
