Go GORM 的 preload 与 join 查询性能对比：N+1 问题的彻底解决方案

先看清 N+1 到底怎么来的

用 GORM 做用户和订单这类一对多关联查询时，很容易掉进一个性能讨论：到底用 Preload 还是 Joins？有人担心 Preload 会产生大量 SQL，有人想用 Joins 却一直遭遇 Scan 困扰。坦白说，这个问题没有标准答案，但如果你不理解 GORM 在两种方式下真正执行的 SQL 和内存策略，很容易用错。

Go GORM 的 preload 与 join 查询性能对比：N+1 问题的彻底解决方案

在讨论 Preload 和 Joins 之前，先明确一个基础概念：N+1 问题。它指主表查出 N 条记录后，为了拿到每条记录关联的数据，又执行了 N 次关联查询。假设主查询是 1 次，总查询次数就是 1 + N。很多新手在循环里直接对每条记录执行查询，这是最典型的写法。

先看一段反面示例：

var users []User
db.Find(&users)
for i := range users {
    db.Model(&users[i]).Association("Orders").Find(&users[i].Orders)
}

这段代码执行了 1 次主查询和 N 次订单查询。当用户量只有几十时还能接受，一旦到几百，每次页面请求都会把数据库拖得很慢。真正需要解决的不是“用不用循环”，而是“如何批量取出关联数据”。

Preload：批量查询，而不是逐条查询

GORM 的 Preload 方法，正是为了把上面的 N 次关联查询压缩成少量批量查询。调用方式很简单：

var users []User
db.Preload("Orders").Find(&users)

实际执行时，GORM 会先查询 users 表，拿到所有用户 ID，然后生成一条 WHERE user_id IN (…) 的查询，一次把订单拉回来，最后在内存里做映射。以 MySQL 为例，大概会执行这样两条 SQL：

SELECT * FROM users;
SELECT * FROM orders WHERE user_id IN (1,2,3,...);

也就是说，Preload 并没有把 N+1 变成 2 次查询中的第二层循环，而是把 N 次查询换成一次 IN 查询。所以，只要 Preload 的关联数量有限，总查询次数基本是常量。

Preload 还支持嵌套，比如 db.Preload("Orders.Items")，它会继续对 Items 做一次类似查询。代码写起来很直观，关联深度大时优势尤其明显。

但 Preload 并非没有代价。最直接的瓶颈是 IN 列表长度。如果 users 表有几万条记录，Preload 生成的 SQL 里可能包含上万个参数。很多数据库对参数数量有限制，比如 MySQL 的 max_allowed_packet、SQLite 的变量上限等。这时你需要把 ID 分批加载，否则查询会失败或显著变慢。

Joins：一条 SQL 背后的隐形成本

既然 Preload 会产生多条 SQL，很多人自然想到用 SQL 的 JOIN 一次搞定。GORM 的 Joins 也提供了这个入口：

var users []User
db.Joins("JOIN orders ON orders.user_id = users.id").Find(&users)

但这里有个容易忽略的细节：GORM 的 Find 只会把 users 表字段扫到 User 结构体，orders 表字段是无法自动填充到 User.Orders 中的。要取订单数据，必须定义额外结构体并手动指定字段：

type UserWithOrder struct {
    ID      uint
    Name    string
    OrderID uint
    Amount  float64
}

var results []UserWithOrder
db.Model(&User{}).
    Select("users.id, users.name, orders.id AS order_id, orders.amount AS amount").
    Joins("JOIN orders ON orders.user_id = users.id").
    Scan(&results)

查询结果里，有多个订单的用户会重复出现。要在代码里还原成 User -> Orders 的结构，还得自己做分组。写出来的代码往往比 SQL 本身还绕。

而且 Joins 在遇到多层关联时，SQL 会变得非常复杂。比如用户、订单、订单商品三层关联，一条 JOIN 会把所有列拼在一起，产生笛卡尔积。如果数据量大，应用层要处理大量冗余字段，内存和网络开销可能超过多次小查询。

Preload 与 Joins：关键差异对比

下面这张表可以快速建立判断框架：

维度	Preload	Joins
SQL 查询次数	主查询 + 每个关联一次	通常一条，但可能很复杂
代码可读性	高，嵌套关联友好	低，需要自定义结构和 Scan
嵌套关联处理	自动支持	需要手动处理字段和映射
数据量大时	IN 列表可能过长	结果集膨胀，传输冗余数据
分页支持	稳定，不影响主查询	需要小心重复行导致分页不准
典型场景	常规列表、多层级数据	统计查询、基于关联表的过滤

性能对比：不能只看查询次数

很多性能测试的结论互相矛盾，原因在于他们没控制变量。Preload 的优势在于 SQL 简单、索引容易命中、传输数据紧凑。Joins 的优势在于一次网络往返，省去了多次请求的延迟。但在内网环境下，几次往返的开销远小于大量冗余数据的传输成本。

举个实际例子：一个后台用户列表页，每页渲染 20 个用户，每个用户平均 30 笔订单。用 Preload 只需要 2 次查询，传输 20 个用户和 600 笔订单的数据。用 Joins 则需要传输 600 行拼出来的结果，每行都包含用户信息，用户名字段重复 30 次。再加上应用层去重，这个额外成本明显高于多次查询的网络延迟。

反过来，如果要做全量统计，比如计算每个用户订单总额，需要按用户分组。此时用 Joins 加 GROUP BY 一步完成，远比 Preload 拉全量数据再在应用层聚合高效。