GORM查询性能优化需禁用默认事务、精简Preload字段、确保FindInBatches主键单调递增、Select指定字段、合理配置连接池；避免N+1、全表扫描与未索引查询。
Go语言集成GORM做ORM开发，关键不在“会不会用”，而在“怎么避免踩坑”——尤其在查询性能、内存开销和连接稳定性上。很多项目上线后才暴露慢查询、连接耗尽、N+1等问题，其实从模型设计和首条查询语句开始就埋下了伏笔。
模型定义要克制，别让结构体变成全字段搬运工
很多开发者习惯把数据库所有字段都映射到结构体里，甚至加一堆未使用的关联字段和钩子。这会显著增加内存分配和序列化开销，尤其在批量查询时。
- 只声明业务真正需要的字段，用
gorm:"-"显式忽略不需要的列 - 关联字段（如
Orders []Order）默认不加载，需明确调用Preload或Joins - 避免在模型中滥用
AfterFind等钩子处理非核心逻辑，它们会在每次查询后无条件执行 - 表名、字段名尽量显式指定，禁用自动复数规则（
gorm.NamingStrategy{SingularTable: true}），减少运行时反射推导
查询必须带约束，禁止裸Find或First
像db.Find(&users)这种没有Where、Limit的调用，在数据量增长后极易演变为全表扫描，且无法被索引覆盖。
- 所有列表查询强制加
Limit（如db.Limit(50).Find(&users)），防止意外拉取海量数据 - 主键查询优先用
First或Take，但务必确认ID存在；否则用Where("id = ?", id).First更可控 - 条件查询统一走
Where链式构建，避免字符串拼接，既防SQL注入也利于查询计划复用 - 需要统计总数时，慎用
Count配合Find——应拆分为独立Count语句，避免拖慢主查询
JOIN和预加载必须按需启用，警惕N+1陷阱
N+1是GORM最典型的性能杀手：查10个用户，再为每个用户单独查一次订单，总共发起11次SQL。表面代码简洁，实则IO爆炸。
立即学习“go语言免费学习笔记（深入）”；
- 一对多关联必须用
Preload一次性加载，如db.Preload("Orders").Find(&users) - 复杂多表关联优先考虑
Joins+Select，手动控制字段粒度，避免GORM自动生成冗余LEFT JOIN - 慎用
Association方法（如user.Orders），它会在访问时触发延迟查询，极易引发隐式N+1 - 对高频查询场景，可考虑用原生SQL或
Raw替代深度嵌套的Preload，控制执行计划更直接
连接池和索引是地基，不配好其他都白搭
GORM本身不管理连接池，它依赖底层*sql.DB。默认配置在生产环境几乎必然出问题。
- 初始化后立刻获取
db.DB()，设置SetMaxOpenConns（建议100）、SetMaxIdleConns（20~30）、SetConnMaxLifetime（1小时） - 数据库表必须为常用查询字段建索引：WHERE字段、ORDER BY字段、JOIN ON字段缺一不可
- 对
LIKE '%xxx'类模糊查询，普通B-Tree索引无效，需考虑全文索引或倒排结构 - 定期用
EXPLAIN分析慢查询，结合MySQL的slow_query_log定位未走索引的语句
