N+1 問題 — 1回で済むはずの問い合わせが100回になる

What — なぜ回数が増えるのか

ORM は「関連を辿ると自動で取ってくる」という便利さを提供します。この便利さが、問い合わせ回数を隠します。

3つの対処法

// Rails
Product.includes(:category).limit(100)

// Prisma
prisma.product.findMany({ take: 100, include: { category: true } })

// 発行されるクエリ
SELECT * FROM products LIMIT 100;
SELECT * FROM categories WHERE id IN (3, 5, 8, ...);   -- 1回にまとまる

→ 101回 が 2回 になる

Why — なぜ気づきにくいのか

N+1 が厄介なのは、あらゆる指標で「正常」に見えることです。

• スロークエリログに出ない。 1回2msのクエリは、どんな閾値にも引っかからない
• CPU 使用率は上がらない。 待っているだけなので、負荷としては見えない
• プロファイラで特定の関数が重く見えない。 時間が広く薄く分散する
• 開発環境では再現しにくい。 データが10件なら11回のクエリで、体感できない

そして最大の理由は、コードを読んでも分からないことです。

for (const product of products) {
  console.log(product.category.name);   // ← ここでクエリが飛ぶ
}

product.category はプロパティアクセスに見えます。しかし ORM の遅延ロードによって、この行でネットワーク往復が発生している。ループの中に I/O があることが、構文から読み取れません。

往復回数が効く理由

1回のクエリが 2ms でも、実際にかかる時間はこうなります。

アプリ → DB のネットワーク往復:  15ms（同一 AZ でも 0.5〜1ms、別 AZ なら数ms）
DB のクエリ実行:                  2ms
                                 ────
                                 17ms × 200回 = 3.4秒

支配的なのはクエリの実行時間ではなく、往復の回数です。 だから対処法も「クエリを速くする」ではなく「回数を減らす」になります。

これは HTTP/1.1 のリクエスト数問題と同じ構造です。1件あたりのコストが小さくても、回数が積み上がれば支配的になる。

演習 — まず自分で判断する

解説を読む前に、まず自分で判断してみてください。ここで一度詰まっておくと、 次の節の判断軸が「なるほど」ではなく「そう来たか」に変わります。