N+1問題とは何ですか？

一覧データを取得する1回のクエリに加え、各行に関連するデータを取得するクエリがN回発行されてしまうパフォーマンス問題。ORMを使うときに特に発生しやすい。

N+1問題のポイントは？

一覧取得の1回 + 各行の関連データ取得N回 = N+1回のクエリが発行される。ORMの遅延ロード（Lazy Loading）が原因で無意識に発生しやすい。Eager Loading（事前一括読み込み）やJOINで解決できる。データ量が少ないと気づきにくく、本番で問題化することが多い

【えぬぷらすわんもんだい】

N+1問題とは？

💡 「1回で済むはずのクエリがN回余計に走る」パフォーマンス問題

📌 このページのポイント

一覧取得の1回 + 各行の関連データ取得N回 = N+1回のクエリが発行される
ORMの遅延ロード（Lazy Loading）が原因で無意識に発生しやすい
Eager Loading（事前一括読み込み）やJOINで解決できる
データ量が少ないと気づきにくく、本番で問題化することが多い

N+1問題の仕組み

ひよこ

N+1問題って具体的にどういう状態？

ペンギン先生

例えば「記事一覧と各記事の著者名を表示する」場面。まず「SELECT * FROM articles」で記事を10件取得（1回目）。次にループで各記事の「SELECT * FROM users WHERE id = ?」を10回実行（N回）。合計11回のクエリが走る。JOINすれば1回で済むのにね。

ひよこ

なんでこんなことが起きるの？

ペンギン先生

ORMの遅延ロード（Lazy Loading）が主な原因。「article.author」にアクセスしたときに初めてクエリが走る仕組みだと、ループ内で毎回クエリが発行される。コード上は「article.author.name」と書いただけなのに、裏でSQLが走っていることに気づかないんだ。

ひよこ

どうやって解決するの？

ペンギン先生

Eager Loading（事前にまとめて読み込む）が王道。RailsならArticle.includes(:author)、LaravelならArticle::with('author')と書くと、記事取得と著者取得が2回のクエリで済む。もしくはJOINで1回のクエリにまとめることもできるよ。

ひよこ

Eager Loadingにしておけば万事解決？

ペンギン先生

単純にはそうなんだけど、Eager Loadingも「使わないリレーションまでEagerにする」と無駄なデータを読み込んでしまう。さらにネストしたリレーション（記事→著者→所属組織→所在地...）をどこまでEagerにするかの判断が厄介。深くEagerにしすぎると1クエリが巨大なJOINになって、それはそれで遅い。画面ごとに必要なリレーションだけをEagerにする設計が大事なんだけど、画面要件が変わるたびに修正が必要になるからメンテナンスコストとの戦いでもあるんだ。

まとめ：ざっくりこれだけ覚えればOK！

N+1問題って出てきたら「1+N回もクエリが走る無駄な状態で、JOINやEager Loadingで1〜2回に減らせる」と思えばだいたいOK！

📖 おまけ：英語の意味

「N+1 Problem」＝ N+1回の問題

💬 1回の一覧取得 + N件分の追加クエリで「N+1」。本来1〜2回で済むはずなのにN+1回走るという意味

← 用語集にもどる

N+1問題 とは？

N+1問題とは？