GraphQL 中的 N+1 问题是什么，DataLoader 如何解决它？

Question

IT Interview Practice · Accepted Answer

**N+1 问题**发生在某个字段的 resolver 对每个 parent 项各运行一次，而每次运行都发起自己的数据库查询时。取回 N 篇 post 的列表、再取每篇 post 的 author，会触发 **1 次查询取 posts + N 次查询取 authors**——共 N+1 次往返，在高负载下会拖垮性能。

## 它为什么会发生

resolver 是按字段、按项运行的。`Post.author` 对列表里的每篇 post 都单独执行，彼此互不知情，于是每个都各自做 `findById`。

```js
// 反例：每篇 post 一次 DB 调用 -> N+1
const resolvers = {
  Post: {
    author: (post, _a, ctx) => ctx.db.users.findById(post.authorId),
  },
};
```

## DataLoader：批处理 + 缓存

**DataLoader** 会把同一 tick 内发起的一个个 `.load(id)` 调用推迟，然后把收集到的 key 交给一个**批处理函数（batch function）**，用单次查询把它们全部取回。它还会在请求内**按 key 缓存**，所以重复的 id 是零成本的。

```js
import DataLoader from "dataloader";

// 每个请求创建一个 loader（挂到 context 上，让缓存限定在请求范围内）
const userLoader = new DataLoader(async (ids) => {
  // ids 到达时形如 [1, 2, 3, ...] -> 单次批处理查询
  const users = await db.users.findByIds(ids);
  // 必须按与 ids 相同的顺序返回值
  return ids.map((id) => users.find((u) => u.id === id));
});

const resolvers = {
  Post: {
    author: (post, _a, ctx) => ctx.userLoader.load(post.authorId), // 批处理
  },
};
// 现在 N 个 author resolver 合并成 1 次查询：总共 2 次查询，而非 N+1。
```

两条规则：**按请求**创建 loader（不要全局共享——否则会在用户之间泄露过期数据），并且批处理函数必须**严格按 key 顺序**返回结果。

## 为什么这很重要

N+1 是最常见的 GraphQL 性能陷阱，也几乎是必考题。展示你会用 DataLoader——并且知道它*为什么*必须限定在请求范围内且保持顺序——说明你有真实的生产经验。

它为什么会发生

DataLoader：批处理 + 缓存

为什么这很重要

相关问题