N+1クエリ — ループの中でDBを叩く

一覧ページが、表示件数が増えるほど遅くなる。10件なら快適なのに、100件で明らかにもたつく。その多くはこのN+1クエリです。

横にスクロール

症状：どう気づくか

• 一覧の表示件数に比例して応答が遅くなる。
• DBのスロークエリログに、ほぼ同じSELECTが何十回も並ぶ（WHERE user_id = ? の ? だけ違う）。
• APM（監視ツール）で1リクエストのクエリ本数が数十〜数百になっている。

たとえば「投稿一覧と、各投稿の著者名」を出すコード。

posts = Post.all              # 1回：投稿を全部引く
posts.each do |post|
  puts post.author.name       # N回：投稿ごとに著者を引く
end

post.author に触れるたび、ORMが裏で SELECT * FROM users WHERE id = ? を発行します。投稿が100件なら、1（投稿）+ 100（著者）= 101回のクエリになります。

なぜ悪いのか

問題は1回のクエリの重さではなく、回数です。DBへの1往復には、クエリ自体の実行時間とは別に、ネットワークの往復遅延（RTT）が乗ります。1回0.5msでも、100回で50msがまるまる待ち時間として積み上がる。件数が増えるほど線形に悪化し、しかもORMが遅延ロードで自動的にやってしまうため、ソースを読んでも「ループの中でDBを叩いている」ようには見えません。ここが厄介さの本質です。

直し方

原則は「必要なものを、まとめて引く」。

eager loading（プリロード）：関連を先読みするようORMに指示する。多くのORMが includes / with / prefetch_related といった仕組みを持ちます。

posts = Post.includes(:author).all   # 2回にまとまる
posts.each { |post| puts post.author.name }  # 追加クエリは発生しない

これで発行されるのは「投稿を引く1回」と「登場する著者IDをまとめて引く1回（WHERE id IN (...)）」の2回だけになります。

まとめ

• N+1は、親1回のあとに子をN回引いてしまう定番の性能事故。件数に比例して遅くなるのが特徴。
• 原因は往復回数。1回が速くてもレイテンシ×Nが積み上がる。ORMの遅延ロードが自動でやるため気づきにくい。
• 直し方は「まとめて引く」。eager loading をまず試し、必要なら JOIN や IN句一括、分散取得なら DataLoader。
• ただし引きすぎも別の害。その画面で使う関連だけを先読みする。