事务不独占连接池，而是从池中借取一个连接并持有至结束；若SetMaxOpenConns过小、并发高，则连接排队导致延迟飙升或超时。
事务执行时会独占连接池里的连接吗
不会。GORM 的事务本身不“占用”连接池之外的资源，但 db.Transaction() 回调内部使用的 *gorm.DB 实例会从底层 *sql.DB 连接池中获取一个连接，并在整个事务生命周期内持有它——直到回调函数返回、显式 Commit() 或 Rollback()，或发生 panic 被自动捕获。这个连接在事务结束前不会归还给空闲池，但也不会阻塞其他 goroutine 获取新连接（只要连接池还有余量）。
关键点在于：事务只是“借走”一个连接，不是“锁死整个池”。如果 SetMaxOpenConns 设得太小，而并发事务数又高，就会出现排队等连接，表现为 P99 延迟飙升、甚至超时。
为什么事务里调用 db.Session() 可能导致连接泄漏
db.Session(&gorm.Session{NewDB: true}) 会创建一个全新、独立的 *gorm.DB 实例，它底层仍复用同一个 *sql.DB 连接池，但它的事务行为不受父 db 控制。更危险的是：如果你在事务回调里又开一个 NewDB: true 的 session 并执行查询，它会额外再拿一个连接——而这个连接不会随外层事务结束自动释放，容易造成连接堆积。
- 避免在
Transaction()回调里使用NewDB: true - 如需隔离上下文（比如不同日志级别），用
WithContext()或Session(&gorm.Session{Context: ctx})即可，不触发新连接分配 - 务必确认所有手动
Begin()都配对Commit()或Rollback()，否则连接永不归还
SkipDefaultTransaction: true 和连接池的关系
这个配置只影响 GORM 是否对每个写操作（Create/Update/Delete）自动包裹一层事务。它**完全不改变连接池行为**——开启时，每次写操作都从池里取连接、开事务、提交/回滚、归还；关闭后，还是同样取连接、执行语句、归还。区别只在 SQL 层是否多两行 BEGIN/COMMIT。
但它间接影响连接池压力：
- 开启默认事务 → 每次写操作都经历一次事务开销（哪怕单条语句），连接周转更快，但短事务频繁切换可能增加上下文切换成本
- 关闭后，你必须显式用
Transaction()包裹业务逻辑块 → 更少但更长的事务，连接持有时间拉长，对SetConnMaxLifetime和空闲连接回收更敏感 - 生产环境几乎都设为
true，因为手动控制更可控，也避免意外的隐式事务嵌套
事务场景下连接池参数怎么调才不翻车
事务本身不改变连接池配置逻辑，但会让参数不合理的问题立刻暴露。比如：
-
SetMaxOpenConns=10，但业务有 15 个并发下单请求，每个走Transaction()→ 5 个请求卡在acquireConn，日志里全是context deadline exceeded -
SetConnMaxLifetime=0（永不过期），云数据库主备切换后，旧连接还在池里复用 → 下次事务里执行第一条语句就报read: connection reset by peer - 没调
db.Session(&gorm.Session{}).Ping()，上线后第一个事务请求因 DNS 解析失败直接 panic，整个服务首请求全挂
真实压测时，盯着 sqlDB.Stats().InUse 和 .Idle 两个指标看：如果 InUse 长期等于 MaxOpen，说明池子不够；如果 Idle 高但 InUse 波动剧烈，可能是 SetConnMaxLifetime 太短，连接频繁重建。
