GORM默认不显式设隔离级别，实际沿用MySQL默认的REPEATABLE READ，其间隙锁在高并发写场景易引发锁竞争、死锁和排队；若业务可接受不可重复读，降级为READ COMMITTED可减小锁范围、提升吞吐。
为什么 GORM 默认隔离级别可能拖慢高并发
GORM 默认不显式设置隔离级别，实际行为取决于底层 MySQL 的 autocommit 状态和会话默认值。多数 MySQL 实例默认是 REPEATABLE READ，它通过间隙锁（gap lock）防止幻读，但在高频写入场景下容易引发锁竞争、死锁或事务排队——这不是 GORM 的 bug，而是隔离级别本身的代价。
如果你的业务能接受「读已提交」语义（比如订单状态轮询、报表统计、日志类写入），降级到 READ COMMITTED 能显著减少锁范围，提升吞吐。但要注意：它不能防止不可重复读，同一事务内两次 SELECT 可能拿到不同结果。
- 确认当前 MySQL 默认隔离级别：
SELECT @@transaction_isolation; - 检查是否全局生效：
SHOW VARIABLES LIKE 'transaction_isolation'; - 别依赖
SET autocommit = 0来“绕开”隔离——它只关自动提交，不改隔离级别
在 GORM 事务中显式设为 READ COMMITTED
GORM 不提供全局默认隔离级别配置，必须在每个需要降级的事务块里手动指定。用 db.Session() + gorm.SessionConfig 是最可靠方式，比拼 SQL 字符串更安全、可读性更强。
示例：
err := db.Session(&gorm.SessionConfig{PrepareStmt: true}).Transaction(func(tx *gorm.DB) error {
// 强制该事务使用 READ COMMITTED
tx.Exec("SET TRANSACTION ISOLATION LEVEL READ COMMITTED")
if err := tx.Create(&order).Error; err != nil {
return err
}
return tx.Model(&user).Where("id = ?", userID).Update("status", "processed").Error
})
-
tx.Exec必须在事务开始后、任何实际操作前调用，否则可能无效 - 不要用
db.Set("gorm:query_option", "...")——它只影响单条查询，不作用于整个事务 - PostgreSQL 用户注意：
READ COMMITTED是它的默认级别，无需额外设置；MySQL 才需要显式干预
读写分离场景下，隔离级别降级要避开的坑
启用 dbresolver 插件后，GORM 会把 SELECT 路由到从库，但事务内所有操作（包括 SELECT）强制走主库——这是为了保证事务一致性。所以你设了 READ COMMITTED，只对主库生效；从库的隔离级别由其自身配置决定，且不受事务控制。
这意味着：如果你在事务里做 SELECT 再 UPDATE，哪怕只读一次，也完全不走从库，降级效果只体现在主库锁行为上，不会降低从库压力。
- 不要指望降级隔离级别能让读请求分流到从库——事务内读永远走主库
- 如果想减轻主库读压力，得把「可容忍脏/旧数据」的读操作拆出事务，单独走从库
- 验证是否生效：开启 GORM 日志，看事务内第一条 SQL 前是否有
SET TRANSACTION ISOLATION LEVEL...
连接池与隔离级别配合调优的关键点
隔离级别降级只是优化一环。若连接池 SetMaxOpenConns 过小，即使锁争抢少了，请求仍卡在等待连接上；若过大，MySQL 的 max_connections 可能被打满，报错 too many connections。
建议组合配置：
- 主库连接池：适当提高
SetMaxOpenConns（如 100），因为降级后单个事务持锁时间变短，连接复用率上升 - 从库连接池：保持独立配置，
SetMaxIdleConns建议不低于SetMaxOpenConns的 50%，避免频繁建连 - 务必设置
SetConnMaxLifetime（如 1h），防止长连接因网络中断或数据库重启变成僵尸连接
真正卡吞吐的，往往不是隔离级别本身，而是连接没及时释放、SQL 没走索引、或者事务里混进了 HTTP 调用这类阻塞操作——这些比改 READ COMMITTED 更值得优先排查。
