Golang并发访问数据库要注意什么_Golang数据库并发设计

数据库连接池配置不当、事务跨goroutine使用、Scan类型不匹配、长事务及锁竞争是Go并发DB操作四大隐患，需分别优化连接参数、限定事务作用域、规范空值处理、缩小事务粒度并避免死锁。

数据库连接池配置不合理会导致大量 goroutine 阻塞

Go 的 database/sql 自带连接池，但默认配置（MaxOpenConns=0、MaxIdleConns=2）在高并发下极易成为瓶颈。当并发请求超过空闲连接数且新连接未及时建立时，db.Query 或 db.Exec 会阻塞等待，goroutine 积压，最终拖垮服务。

• MaxOpenConns 建议设为略高于峰值 QPS（如 QPS 100 → 设为 120），避免连接耗尽；设为 0 表示无限制，但可能压垮数据库
• MaxIdleConns 应 ≤ MaxOpenConns，通常设为 MaxOpenConns 的 1/2～2/3，减少连接反复创建销毁开销
• 务必调用 db.SetConnMaxLifetime（如 30m）和 db.SetConnMaxIdleTime（如 5m），防止 stale connection 和连接泄漏

事务内不能跨 goroutine 使用同一个 *sql.Tx

*sql.Tx 不是并发安全的。在事务中起 goroutine 并复用该 tx 执行查询或更新，大概率触发 sql: Transaction has already been committed or rolled back 或静默失败——因为主线程可能已提前 Commit()/Rollback()，而子 goroutine 还在用已失效的句柄。

• 事务必须严格限定在单个 goroutine 内完成：从 db.Begin() 到 tx.Commit() 或 tx.Rollback() 之间不 spawn 新 goroutine 操作该 tx
• 若需并行执行多个独立 DB 操作，应为每个 goroutine 分配独立的 *sql.DB 句柄（走连接池）或各自 Begin() 新事务
• 切勿把 tx 当参数传给异步函数，也不要在闭包里捕获并延迟使用它

Scan 时未处理 sql.NULL* 或类型不匹配会 panic

并发场景下，panic 更危险：一个 goroutine panic 若未 recover，可能终止整个程序（尤其没启用 recover 的 http handler）。常见于 select nullable_column FROM t 后直接 Scan 到非空类型（如 int 而非 sql.NullInt64）。

• 对可能为 NULL 的列，必须使用对应 sql.Null* 类型（sql.NullString、sql.NullBool 等），并检查 .Valid 字段
• 避免用 Interface{} + 类型断言接收 Scan 结果，易因底层 driver 返回类型差异（如 []byte vs string）导致 panic
• 批量查询建议用 rows.Scan(&v1, &v2) 显式绑定，而非 rows.Columns() 动态解析，减少运行时不确定性

长事务 + 高并发容易触发数据库锁等待或死锁

postgresql/mysql 在 RR 或 RC 隔离级别下，并发 UPDATE/delete 同一行或相邻索引范围时，可能因锁升级、间隙锁或锁等待超时（如 MySQL 默认 innodb_lock_wait_timeout=50）导致操作失败，错误信息类似 Error: deadlock detected 或 ERROR 1205 (HY000): Deadlock found when trying to get lock。

立即学习“go语言免费学习笔记（深入）”；

• 事务粒度尽量小：只包必要 SQL，避免在事务内做 HTTP 请求、文件读写等耗时操作
• 按固定顺序访问多张表或同一表的不同行（如总是先更新 user 表再更新 order 表，且 user_id 升序），降低死锁概率
• 对冲突热点（如计数器、库存），考虑用原子 SQL（UPDATE t SET cnt = cnt + 1 WHERE id = ?）替代 SELECT+UPDATE，减少锁持有时间

实际并发 DB 操作中最容易被忽略的，是事务生命周期与 goroutine 边界的一致性——不是“用了 go func(){}() 就算并发”，而是每个 DB 操作单元的资源归属、错误传播、超时控制都得独立闭环。否则表面并发，实则暗藏竞态和雪崩风险。