GORM事务本身不慢，慢的是事务边界失控、锁竞争未处理、日志/钩子未关闭；90%卡顿源于事务内混入HTTP调用、文件IO等非DB操作，导致连接池堵塞和锁等待。
GORM 事务本身不慢，慢的是你没控制好事务边界、没处理好锁竞争、也没关掉不必要的日志和钩子。线上事务卡顿，90% 不是 GORM 的锅，而是事务里混进了不该有的操作。
事务里执行了非数据库操作
常见错误现象：接口耗时突增，pprof 显示大量时间卡在 time.Sleep、http.Do 或 json.Marshal，但 SQL 日志看起来正常。
使用场景：支付回调里一边更新订单状态，一边调第三方通知接口；或者事务中做文件写入、发邮件、生成 PDF。
为什么这样做不行：事务会一直持有数据库连接 + 行锁/表锁，外部 IO 一卡，整个连接池就堵住。GORM 默认的连接池大小通常只有 10–30，5 个慢事务就能让后续请求排队等锁。
- 把 HTTP 请求、文件读写、复杂计算等全部移出
Transaction()回调函数 - 如必须异步通知，先记日志或发 MQ，再由独立 worker 处理
- 若需保证最终一致性，用
AfterCommit钩子（仅限 GORM v1.21+），它在事务提交后触发，不阻塞连接释放
长事务 + 未加索引的 WHERE 条件导致锁等待
常见错误现象：SHOW PROCESSLIST 看到一堆 Waiting for table metadata lock 或 Updating 状态；INFORMATION_SCHEMA.INNODB_TRX 显示事务运行超 30 秒且 TRX_ROWS_LOCKED 很高。
使用场景：后台导出功能用事务包住百万行 UPDATE；或批量任务里用 WHERE name LIKE "%xxx%" 更新用户状态。
性能影响：无索引的 WHERE 会触发全表扫描 + 全表加锁；MySQL 在 RR 隔离级别下会对扫描到的所有行加 gap lock，极易引发锁冲突。
- 事务内只操作必要行：UPDATE 前先用带索引的条件查 ID 列表，再用
IN批量更新 - 避免在事务里做
LIKE "%xxx"、DATE(created_at)、隐式类型转换（如WHERE user_id = "123"） - 给高频更新字段建联合索引，比如
INDEX idx_status_updated (status, updated_at)
事务嵌套不当 + panic 导致连接泄漏
常见错误现象：服务运行几小时后，数据库连接数持续上涨，SHOW STATUS LIKE 'Threads_connected' 达到 max_connections；pprof/goroutine?debug=2 显示大量 goroutine 卡在 semacquire 上。
使用场景：手动调用 Begin() 后忘了 Commit() 或 Rollback()；或在事务回调里 panic 但没 recover。
为什么容易被忽略：GORM 的 Transaction() 函数内部已做 recover，但手动事务不会自动兜底——它把连接控制权完全交给你。
- 永远用
defer func() { if tx.Error != nil { tx.Rollback() } }()包裹手动事务 - 禁止在事务中直接 panic；错误统一用
return err，让 GORM 自动 rollback - 生产环境开启
SetConnMaxLifetime和SetMaxOpenConns，防止泄漏连接长期占位
线上诊断必须打开的三个开关
不配这三项，你根本看不到事务真实瓶颈在哪。
第一是慢查询日志：设 SlowThreshold: 100 * time.Millisecond，并确保日志输出包含 RowsAffected 和执行时间，否则看不出是锁等还是 SQL 慢。
第二是数据库锁视图：MySQL 必须定期查 SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX ORDER BY TRX_STARTED LIMIT 10，看谁持锁最久；PostgreSQL 查 pg_stat_activity 和 pg_locks 关联。
第三是 Go 层 pprof：访问 /debug/pprof/goroutine?debug=2 抓全量栈，重点搜 Begin、Commit、QueryContext 调用链，确认 goroutine 是真卡 DB 还是卡在别处。
最容易被忽略的其实是事务上下文透传——HTTP handler 里开的事务，如果中间经过了中间件或 context.WithTimeout，而没把 *gorm.DB 正确传递下去，会导致事务失效或连接复用错乱。这点在线上压测时才暴露得最清楚。
