禁用默认事务可提速但需分场景:全局用SkipDefaultTransaction:true,单次用Session;Preload需精简字段防N+1;FindInBatches要求主键单调递增;Select字段和QueryFields模式减少开销;连接池与context不可忽视。

禁用默认事务能提速,但得看场景
写操作(Create、Update、Delete)默认被 GORM 包进事务里,确保数据安全,但也带来开销。如果你的业务不依赖事务强一致性(比如日志记录、埋点上报),关掉它能明显降低延迟。
- 全局禁用:
SkipDefaultTransaction: true配置在gorm.Config里 - 只对某次操作禁用:用
Session(&gorm.Session{SkipDefaultTransaction: true}) - 别在需要原子性的场景关——比如扣库存+生成订单,必须共用一个事务,否则可能超卖
- MySQL 下关事务后,
LAST_INSERT_ID()可能失效,影响自增主键获取
Preload 不是万能药,N+1 还是会悄悄回来
Preload 能一次性加载关联数据,避免循环中查数据库,但用错照样变慢甚至更糟。
- 只预加载真正要用的字段:用
Preload("Orders", db.Select("id", "user_id", "amount")),别让 GORM 拉回整张 orders 表 - 嵌套预加载要小心:
Preload("Orders.Items")如果 orders 和 items 都很多,会爆炸式放大结果集 - 如果只是判断“有没有订单”,用
Preload("Orders", db.Select("id").Limit(1))或直接改用Joins+Count - PostgreSQL 用户注意:
Preload在一对多时可能触发笛卡尔积,不如显式Joins+Scan控制精准
FindInBatches 是大数据导出的救命稻草,但主键必须靠谱
查几百万条数据?别用 Find,也别手写 LIMIT/OFFSET 分页——FindInBatches 是 GORM 唯一推荐的大批量迭代方案。
初始化并管理阿里云SDK Go 客户端,涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 它内部按主键游标推进,每次只查
WHERE id > ? ORDER BY id LIMIT N,性能稳定不衰减 - 必须保证主键是单调递增且无空洞(比如 UUID 或软删除 ID 就不行),否则会漏数据
- 批次大小别设太小(如 10)或太大(如 10000):50–500 是较稳妥区间,视单条记录体积调整
- 别在循环里做耗时操作(如 HTTP 请求、文件写入),否则拖慢整个批次节奏,考虑用 goroutine 异步处理
Select 字段和 QueryFields 模式,少查一个字段就少一分风险
SELECT * 在 Go 里不是懒,是危险。字段多了,内存涨、GC 压力大、结构体字段一不同就 panic。
立即学习“go语言免费学习笔记(深入)”;
- 明确指定字段最安全:
db.Select("id", "name", "email").Find(&users) - 用精简结构体自动推导:
type APIUser struct { ID uint; Name string },再db.Find(&apiUsers),GORM 自动只查这两个字段 - 开启
QueryFields: true后,所有Find都按目标结构体字段查——但要注意:它对嵌套结构体、匿名字段支持有限,容易漏字段 - 敏感字段(如
Password、Token)务必从结构体里剔除,靠Select或结构体定义来隔离,别指望中间件过滤
最常被忽略的是连接池配置和 context 传递——db.SetMaxOpenConns 不设、HTTP handler 里用 context.Background() 执行查询,性能问题再怎么调 Select 和 Preload 也白搭。


















