禁用gorm默认事务可提升30%+写入性能，但需分场景：全局用skipdefaulttransaction:true，单次用session；严禁在扣库存+生成订单等需原子性场景关闭，否则导致超卖。
直接说结论：GORM 本身不慢，慢的是没关默认事务、没设连接池、没躲开 Limit+Offset、没管 Preload 字段粒度——这些不是“进阶技巧”，是上线前必须调的底线配置。
怎么禁用 GORM 默认事务才安全
写操作（Create、Update、Delete）默认包在事务里，有安全性但也有开销。不是所有场景都需要它：
- 日志上报、埋点、缓存更新这类最终一致性操作，可全局关：初始化时加
SkipDefaultTransaction: true到gorm.Config - 单次操作临时关闭：用
db.Session(&gorm.Session{SkipDefaultTransaction: true})，比全局关更可控 - 千万别在扣库存+生成订单这种链路里关——会超卖；MySQL 下关事务后
LAST_INSERT_ID()可能拿不到新 ID
Preload 加了反而更慢？关键在字段和条件
Preload 解决 N+1，但滥用会导致 IN 查询爆炸、内存重复、传输变大：
- 必须用
Select指定字段，且至少包含外键（如user_id）或主键，否则关联失败：db.Preload("Orders", db.Select("id", "user_id", "amount")) - 嵌套预加载（如
Orders.Items）极易触发笛卡尔积，PostgreSQL 尤其明显；优先改用Joins+ 手动Select - 只查“有没有”就加
Limit(1)：db.Preload("Orders", db.Select("id").Limit(1))，别拉全量
分页不能只靠 Limit 和 Offset
数据量过 10 万，OFFSET 就是性能断崖的开关——数据库得扫描并丢弃前 N 行，不是跳过：
- 游标分页才是稳解：
db.Where("id > ?", lastID).Order("id ASC").Limit(50)，前提是主键单调递增、有索引 - 如果 UI 强制要“总条数”，别用
Count()链在查询后面——它可能漏Where条件；改用独立语句：db.Model(&User{}).Where("status = ?", "active").Count(&total) - 真要用
Offset，至少配覆盖索引，让 MySQL 只走索引不回表
连接池不调，其他优化都是空谈
GORM 不管连接池，全靠底层 *sql.DB。默认值（MaxOpenConns=0，不限制）在线上等于开盲盒：
- 立刻执行：
db.DB().SetMaxOpenConns(100)、SetMaxIdleConns(25)、SetConnMaxLifetime(1 * time.Hour) -
MaxOpenConns推荐按公式粗估：(平均查询耗时 ms × 峰值 QPS) / 1000 + 缓冲 20% - 没配好连接池，高并发下直接报
too many connections，连诊断都来不及
最常被忽略的其实是模型定义本身：字段越多，内存分配越重，GC 越频繁；一个没用的 AfterFind 钩子会在每次查询后无条件执行——这些细节不抠，再好的查询也跑不快。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
