N+1 — โค้ด 3 บรรทัดที่เดินไปตู้ 101 รอบ

ภาพก่อนโค้ด: ขอชื่อผู้เขียน 6 คน ต้องเดินไปตู้ 7 รอบ

สมมติหน้าแรกของบล็อกต้องโชว์ "ชื่อบทความ — โดย ชื่อผู้เขียน" ทั้ง 6 ชิ้น
ชื่อบทความอยู่ในลิ้นชัก posts · แต่ชื่อผู้เขียนอยู่อีกลิ้นชักหนึ่ง คือ users · บนแฟ้มบทความมีแค่ช่อง user_id (เลขที่ของผู้เขียน) ไม่มีชื่อ

ถ้าเขียนโค้ดแบบที่คนส่วนใหญ่เขียนตามธรรมชาติ คนดูแลสต็อกจะทำแบบนี้:

ปัญหานี้ชื่อ N+1 — ไปตู้ 1 รอบเพื่อเอารายการ แล้วไปอีก N รอบ (หนึ่งรอบต่อหนึ่งชิ้นในรายการ) · 6 ชิ้นยังไม่รู้สึก · แต่ 100 ชิ้นคือ 101 รอบ และทุกรอบต้องรอฐานข้อมูลตอบ หน้าเว็บจึงช้าลงตามจำนวนข้อมูลไปเรื่อย ๆ

ลองใน console — นับ SELECT ด้วยตาตัวเอง

เปิด bin/rails console ในแอป wongnok_blog ที่มีข้อมูลจากบท 107 · console ของ Rails 8.1 โชว์ SQL ทุกบรรทัดให้อยู่แล้ว ไม่ต้องตั้งอะไรเพิ่ม (ถ้าดูสไลด์หน้า 37 ข้ามบรรทัด ActiveRecord::Base.logger = … ไปได้ — ดูท้ายบท)

คำสั่งที่จะพิมพ์ — "ขอชื่อผู้เขียนของทุกบทความ":

Post.all.map { |p| p.user.name }

• Post.all — ใบเบิกของ "ขอบทความทุกชิ้น" (ยังไม่ไปตู้)
• .map { |p| … } — วนทีละบทความ ตั้งชื่อเล่นว่า p · ตรงนี้แหละที่ใบเบิกถูกยื่น เพราะต้องใช้ข้อมูลจริงแล้ว
• p.user.name — ขอผู้เขียนของบทความนี้ แล้วเอาชื่อ

wongnok-blog(dev):001> Post.all.map { |p| p.user.name }

wongnok-blog(dev):001> Post.all.map { |p| p.user.name }
  Post Load (48.4ms)  SELECT "posts".* FROM "posts" /*application='WongnokBlog'*/
  User Load (1.5ms)  SELECT "users".* FROM "users" WHERE "users"."id" = 1 LIMIT 1 /*application='WongnokBlog'*/
  User Load (1.1ms)  SELECT "users".* FROM "users" WHERE "users"."id" = 1 LIMIT 1 /*application='WongnokBlog'*/
  User Load (1.1ms)  SELECT "users".* FROM "users" WHERE "users"."id" = 2 LIMIT 1 /*application='WongnokBlog'*/
  User Load (1.0ms)  SELECT "users".* FROM "users" WHERE "users"."id" = 2 LIMIT 1 /*application='WongnokBlog'*/
  User Load (1.0ms)  SELECT "users".* FROM "users" WHERE "users"."id" = 3 LIMIT 1 /*application='WongnokBlog'*/
  User Load (1.1ms)  SELECT "users".* FROM "users" WHERE "users"."id" = 3 LIMIT 1 /*application='WongnokBlog'*/
=> ["สมชาย", "สมชาย", "สมหญิง", "สมหญิง", "มานะ", "มานะ"]

แปลบรรทัด SQL เป็นภาษาคน:

• Post Load (48.4ms) — "คนดูแลสต็อกของ Post ไปหยิบแฟ้ม ใช้เวลา 48.4 มิลลิวินาที" (ตัวเลขเวลาเปลี่ยนทุกรอบ ไม่ต้องสนใจ)
• SELECT "posts".* FROM "posts" — "ขอแฟ้มทุกช่อง (*) จากลิ้นชัก posts ทุกแผ่น" → รอบที่ 1
• SELECT "users".* FROM "users" WHERE "users"."id" = 1 LIMIT 1 — "ขอแฟ้มทุกช่องจากลิ้นชัก users เฉพาะแผ่นที่เลขที่ (id) เป็น 1 · เอามาไม่เกินแผ่นเดียว" → รอบที่ 2 ถึง 7
• /*application='WongnokBlog'*/ — ป้ายชื่อแอปที่ Rails แปะท้าย SQL (บท 113) ไม่ต้องสนใจ
• => [...] — ผลของ map คือรายการชื่อ 6 ชื่อ

ทำไมเกิด: post.user คือการ "เดินไปตู้" ไม่ใช่ "อ่านช่องบนแฟ้ม"

ต้นเหตุทั้งหมดอยู่ที่หน้าตาของโค้ด · post.user หน้าตาเหมือนอ่านค่าธรรมดา เหมือน post.title · แต่ข้างในต่างกันมาก — ลองแยกดูทีละคำสั่งใน console (ผลจริง):

wongnok-blog(dev):001> post = Post.first
  Post Load (1.6ms)  SELECT "posts".* FROM "posts" ORDER BY "posts"."id" ASC LIMIT 1 /*application='WongnokBlog'*/
=>
#<Post:0x00000001264959e0
...
wongnok-blog(dev):002> post.user_id
=> 1
wongnok-blog(dev):003> post.user
  User Load (1.8ms)  SELECT "users".* FROM "users" WHERE "users"."id" = 1 LIMIT 1 /*application='WongnokBlog'*/
=>
#<User:0x0000000126c1abe8
 id: 1,
 name: "สมชาย",
 email: "[FILTERED]",
…
wongnok-blog(dev):004> post.user.name
=> "สมชาย"

• post = Post.first — หยิบแฟ้มบทความแผ่นแรกมาถือไว้ (ไปตู้ 1 รอบ · ORDER BY "posts"."id" ASC = เรียงเลขที่น้อยไปมาก)
• post.user_id — ได้ 1 และไม่มีบรรทัด SQL เลย · เพราะเลข 1 เขียนอยู่บนแฟ้มที่ถืออยู่แล้ว แค่อ่าน
• post.user — มีบรรทัด User Load โผล่ · ชื่อผู้เขียนไม่ได้อยู่บนแฟ้มบทความ คนดูแลสต็อกจึงต้องเดินไปลิ้นชัก users · (email: "[FILTERED]" คือ Rails ซ่อนอีเมลไม่ให้โชว์ในจอ — ในตู้ยังเป็นอีเมลจริง)
• post.user.name — ครั้งที่สองไม่ไปตู้แล้ว · บทความแผ่นนี้จำผู้เขียนที่เพิ่งหยิบมาไว้ · แต่จำได้เฉพาะแผ่นนี้ บทความแผ่นอื่นของสมชายไม่รู้เรื่องด้วย — จึงเกิดการไปหาสมชายซ้ำในหัวข้อที่แล้ว

Rails ไม่รู้ล่วงหน้าว่าเราจะถามผู้เขียนของทุกแผ่น · ตอนหยิบแฟ้มบทความมามันจึงไม่หยิบผู้เขียนมาด้วย · พอเราถามทีละแผ่น มันก็ไปตู้ทีละแผ่น — การไปตู้ "ตอนที่ถาม" แบบนี้เรียกว่า lazy loading

คำนี้เจอแล้วในบท 113 · หลักเดียวกัน คือ "ยังไม่ไปตู้จนกว่าจะต้องใช้" · บท 113 ใช้กับใบเบิกของ (Post.where(…)) · บทนี้ใช้กับผู้เขียนของแต่ละบทความ (post.user)

เทียบกับ Go (GORM บท 27): ใน Go ถ้าจะทำ N+1 คุณต้องเขียนคำสั่งไปตู้ในลูปเองกับมือ — เห็นชัดตั้งแต่อ่านโค้ด:

// Go + GORM — N+1 แบบเห็นด้วยตา
var posts []Post
db.Find(&posts)                  // ไปตู้ 1 รอบ
for _, p := range posts {
    var u User
    db.First(&u, p.UserID)        // ไปตู้อีก 1 รอบ ต่อบทความ 1 ชิ้น
    fmt.Println(u.Name)
}

ฝั่ง Rails คำว่า db.First ถูกซ่อนอยู่ใน p.user · โค้ดสั้นและอ่านง่ายกว่า แต่มองไม่เห็นว่ามีการไปตู้ · นี่คือเหตุผลของประโยคหลักวันนี้: N+1 ไม่ได้อ่านจากโค้ด — อ่านจาก log

แก้ด้วยคำเดียว: includes

ทางแก้คือบอก Rails ล่วงหน้าตอนเขียนใบเบิกว่า "เดี๋ยวจะใช้ผู้เขียนด้วยนะ หยิบมาเผื่อเลย" · คำที่ใช้บอกคือ includes(:user) — ชื่อ :user ต้องตรงกับที่เขียนใน model (belongs_to :user)

wongnok-blog(dev):002> Post.includes(:user).map { |p| p.user.name }
  Post Load (2.4ms)  SELECT "posts".* FROM "posts" /*application='WongnokBlog'*/
  User Load (2.0ms)  SELECT "users".* FROM "users" WHERE "users"."id" IN (1, 2, 3) /*application='WongnokBlog'*/
=> ["สมชาย", "สมชาย", "สมหญิง", "สมหญิง", "มานะ", "มานะ"]

• เหลือ 2 บรรทัด จาก 7 · ผลลัพธ์เหมือนเดิมทุกตัวอักษร
• บรรทัดแรกเหมือนเดิม: หยิบบทความทุกแผ่น
• WHERE "users"."id" IN (1, 2, 3) — IN (…) แปลว่า "เฉพาะแผ่นที่เลขที่เป็นตัวใดตัวหนึ่งในวงเล็บ" · ทั้งประโยค = "ขอแฟ้มทุกช่องจากลิ้นชัก users เฉพาะเลขที่ 1, 2 หรือ 3" — Rails อ่านแฟ้มบทความแล้วรวบเลขผู้เขียนมาให้เอง ซ้ำก็ตัดให้
• หลังจากนั้น p.user ไม่ไปตู้แล้ว เพราะผู้เขียนทุกคนถูกหยิบมารอไว้แล้ว

ถ้ามีบทความ 100 ชิ้น ก็ยังเป็น 2 รอบ · จำนวนรอบไม่โตตามข้อมูลอีกต่อไป — ต่างจากเดิมที่ 100 ชิ้น = 101 รอบ

เทียบกับ Go: GORM ก็มีของแบบเดียวกันชื่อ Preload — db.Preload("User").Find(&posts) · เอกสาร GORM บอกว่าได้ SQL สองประโยค: ลิ้นชักหลักหนึ่งรอบ + WHERE … IN (…) อีกหนึ่งรอบ — หน้าตาเดียวกับที่เราเพิ่งเห็น

ในหน้าเว็บจริง — อ่าน log ของ server นับก่อน/หลัง

console ช่วยให้เข้าใจ · แต่ N+1 ตัวจริงเกิดในหน้าเว็บ และซ่อนอยู่ใน view · มาทำหน้า /posts จิ๋ว ๆ (ถ้ามีจากบท 113 แล้ว แก้ให้เป็นแบบนี้):

# config/routes.rb — ใน block ของ draw (บท 101)
resources :posts, only: :index

# app/controllers/posts_controller.rb
class PostsController < ApplicationController
  def index
    @posts = Post.all
  end
end

<%# app/views/posts/index.html.erb %>
<h1>บทความทั้งหมด</h1>
<ul>
  <% @posts.each do |post| %>
    <li><%= post.title %> — โดย <%= post.user.name %></li>
  <% end %>
</ul>

• only: :index — จาก 8 เส้นของ resources เอาแค่เส้น GET /posts เส้นเดียว (เหมือนบท 113 · ละเอียดในบท 117)
• controller วางใบเบิก "บทความทุกชิ้น" ไว้บนถาด @posts (ยังไม่ไปตู้ — บท 113)
• view บรรทัด 1: <%# … %> — แค่โน้ตชื่อไฟล์ (comment ของ ERB ไม่โชว์บนหน้าเว็บ) · บทนี้นับมันเป็นบรรทัด 1
• view บรรทัด 4: @posts.each — วนทีละบทความ (ยื่นใบเบิกตรงนี้)
• view บรรทัด 5: post.user.name — ตัวต้นเหตุ หน้าตาไม่มีพิษภัยอะไรเลย

เปิด bin/rails server หน้าต่างหนึ่ง · tail -f log/development.log อีกหน้าต่าง (บท 113) · แล้วเปิด http://localhost:3000/posts ในเบราว์เซอร์ · ด้านล่างผมใช้ curl แทน (curl = โปรแกรมเปิดหน้าเว็บจากเทอร์มินัล โชว์ HTML เป็นข้อความ · ใช้เบราว์เซอร์ก็ได้ผลเหมือนกัน) — ผลจริง:

$ curl -s localhost:3000/posts
…
      <!-- BEGIN app/views/posts/index.html.erb
--><h1>บทความทั้งหมด</h1>
<ul>
    <li>ต้มยำกุ้งน้ำข้น — โดย สมชาย</li>
    <li>ส้มตำปูปลาร้า — โดย สมชาย</li>
    …
    <li>แกงเขียวหวานไก่ — โดย มานะ</li>
</ul>
<!-- END app/views/posts/index.html.erb -->
…

<!-- BEGIN … --> กับ <!-- END … --> = โน้ตที่ Rails โหมด development แปะบอกว่า "ส่วนนี้มาจาก view ไฟล์ไหน" (เบราว์เซอร์ไม่โชว์ ไม่ต้องสนใจ) · โน้ต BEGIN กินที่ไปหนึ่งบรรทัด — นี่คือเหตุที่เลขบรรทัดของ .erb ใน log เกินจริง 1 (เดี๋ยวเจอข้างล่าง)

หน้าเว็บถูกต้องทุกบรรทัด ไม่มี error · ถ้าดูแค่หน้าเว็บจะไม่มีวันรู้ว่ามีปัญหา · ต้องดูที่ log (ผลจริง):

Started GET "/posts" for ::1 at 2026-11-04 19:04:37 +0700
Processing by PostsController#index as */*
  Rendering layout layouts/application.html.erb
  Rendering posts/index.html.erb within layouts/application
  Post Load (33.8ms)  SELECT "posts".* FROM "posts" /*action='index',application='WongnokBlog',controller='posts'*/
  ↳ app/views/posts/index.html.erb:5
  User Load (1.4ms)  SELECT "users".* FROM "users" WHERE "users"."id" = 1 LIMIT 1 /*action='index',application='WongnokBlog',controller='posts'*/
  ↳ app/views/posts/index.html.erb:6
  CACHE User Load (0.0ms)  SELECT "users".* FROM "users" WHERE "users"."id" = 1 LIMIT 1
  ↳ app/views/posts/index.html.erb:6
  User Load (0.9ms)  SELECT "users".* FROM "users" WHERE "users"."id" = 2 LIMIT 1 /*action='index',application='WongnokBlog',controller='posts'*/
  ↳ app/views/posts/index.html.erb:6
  CACHE User Load (0.0ms)  SELECT "users".* FROM "users" WHERE "users"."id" = 2 LIMIT 1
  ↳ app/views/posts/index.html.erb:6
  User Load (0.9ms)  SELECT "users".* FROM "users" WHERE "users"."id" = 3 LIMIT 1 /*action='index',application='WongnokBlog',controller='posts'*/
  ↳ app/views/posts/index.html.erb:6
  CACHE User Load (0.0ms)  SELECT "users".* FROM "users" WHERE "users"."id" = 3 LIMIT 1
  ↳ app/views/posts/index.html.erb:6
  Rendered posts/index.html.erb within layouts/application (Duration: 57.4ms | GC: 1.1ms)
  Rendered layout layouts/application.html.erb (Duration: 63.3ms | GC: 1.3ms)
Completed 200 OK in 87ms (Views: 4.3ms | ActiveRecord: 59.9ms (7 queries, 3 cached) | GC: 9.6ms)

อ่านแบบนักสืบ — สามที่ที่ต้องดู:

• บรรทัดสุดท้าย (7 queries, 3 cached) — ดูตรงนี้ก่อนเสมอ · 7 คือจำนวนคำถามทั้งหมด · มี 6 บทความแต่ถาม 7 ครั้ง = กลิ่น N+1
• User Load ซ้ำ ๆ กันหลายบรรทัด ต่างกันแค่เลข id — รูปแบบหน้าตาของ N+1 ที่ต้องจำให้ได้
• ↳ app/views/posts/index.html.erb:6 — ชี้ว่าบรรทัดไหนสั่ง · ลบหนึ่ง ได้บรรทัด 5 = post.user.name พอดี (เลขบรรทัดไฟล์ .erb ใน log เกินจริง 1 — บท 113 เตือนไว้ · สาเหตุคือโน้ต <!-- BEGIN … --> ที่เพิ่งเห็นใน HTML)

ถ้าคุณไม่ได้พิมพ์บรรทัด 1 (โน้ตชื่อไฟล์) ทุกบรรทัดในไฟล์จะขยับขึ้นหนึ่ง log ของคุณจึงเป็น :4 กับ :5 แทน :5 กับ :6 (ผมลองแล้วทั้งสองแบบ) · กฎ "ลบหนึ่ง" ยังใช้ได้เหมือนเดิม

ของใหม่ที่ console ไม่มี: CACHE User Load (0.0ms) · นี่คือ query cache ที่เห็นแวบ ๆ ในบท 113 — ระหว่างทำใบสั่งหนึ่งใบ Rails จำคำตอบของคำถามที่เพิ่งถามไว้ ถามซ้ำเป๊ะ ๆ (สมชายรอบที่สอง) ก็ตอบจากความจำ ไม่เดินไปตู้

log จึงนับว่า 7 query แต่ 3 ตัวในนั้นตอบจากความจำ ไปตู้จริง 4 รอบ · ความจำนี้ล้างทิ้งทุกครั้งที่ใบสั่งจบ · ใน console ไม่มีใบสั่ง จึงไม่มีความจำนี้ (ถึงเห็นสมชายสองรอบเต็ม ๆ เมื่อกี้)

ทีนี้แก้ controller บรรทัดเดียว — view ไม่ต้องแตะเลย:

# app/controllers/posts_controller.rb
class PostsController < ApplicationController
  def index
    @posts = Post.includes(:user)
  end
end

รีเฟรชหน้าเดิม · log ใหม่ (ผลจริง):

Started GET "/posts" for ::1 at 2026-11-04 19:04:39 +0700
Processing by PostsController#index as */*
  Rendering layout layouts/application.html.erb
  Rendering posts/index.html.erb within layouts/application
  Post Load (2.4ms)  SELECT "posts".* FROM "posts" /*action='index',application='WongnokBlog',controller='posts'*/
  ↳ app/views/posts/index.html.erb:5
  User Load (1.5ms)  SELECT "users".* FROM "users" WHERE "users"."id" IN (1, 2, 3) /*action='index',application='WongnokBlog',controller='posts'*/
  ↳ app/views/posts/index.html.erb:5
  Rendered posts/index.html.erb within layouts/application (Duration: 19.5ms | GC: 0.0ms)
  Rendered layout layouts/application.html.erb (Duration: 20.8ms | GC: 0.0ms)
Completed 200 OK in 23ms (Views: 9.3ms | ActiveRecord: 12.2ms (2 queries, 0 cached) | GC: 0.0ms)

• (2 queries, 0 cached) — จาก 7 เหลือ 2 · หน้าเว็บที่ได้เหมือนเดิมทุกตัวอักษร
• ทั้งสองบรรทัดชี้ :5 (= บรรทัด 4 คือ @posts.each) — ผู้เขียนถูกหยิบมาพร้อมกันตอนยื่นใบเบิก ไม่ใช่ตอนถาม post.user
• เวลา 87ms → 23ms ในเครื่องผม (6 บทความ ตัวเลขเล็กมาก ของคุณจะต่าง) · สไลด์หน้า 38 อ้างว่า หน้าที่โชว์ 20 โพสต์ใช้ 740ms ก่อนแก้ และ 40–60ms หลังแก้ — ผมไม่ได้วัดเลขชุดนั้น แต่ทิศทางเดียวกัน

includes · preload · eager_load — สามคำ สองวิธี

includes ไม่ใช่คำเดียวที่ทำแบบนี้ได้ · Rails มีวิธีหยิบของที่ผูกกันมาล่วงหน้า สองวิธีจริง ๆ และมีคำสั่งเรียกแต่ละวิธีตรง ๆ · includes คือ "ให้ Rails เลือกวิธีให้"

วิธีที่ 1 — preload: แยกไปสองลิ้นชัก สองรอบ (ผลจริง · เหมือนที่ includes ทำเมื่อกี้ทุกบรรทัด):

wongnok-blog(dev):001> Post.preload(:user).map { |p| p.user.name }
  Post Load (50.4ms)  SELECT "posts".* FROM "posts" /*application='WongnokBlog'*/
  User Load (1.5ms)  SELECT "users".* FROM "users" WHERE "users"."id" IN (1, 2, 3) /*application='WongnokBlog'*/
=> ["สมชาย", "สมชาย", "สมหญิง", "สมหญิง", "มานะ", "มานะ"]

วิธีที่ 2 — eager_load: เย็บสองลิ้นชักเป็นแผ่นเดียว ไปรอบเดียว (ผลจริง):

wongnok-blog(dev):002> Post.eager_load(:user).map { |p| p.user.name }
  Post Eager Load (3.1ms)  SELECT "posts"."id" AS t0_r0, "posts"."title" AS t0_r1, "posts"."body" AS t0_r2, "posts"."created_at" AS t0_r3, "posts"."updated_at" AS t0_r4, "posts"."published" AS t0_r5, "posts"."views" AS t0_r6, "posts"."user_id" AS t0_r7, "users"."id" AS t1_r0, "users"."name" AS t1_r1, "users"."email" AS t1_r2, "users"."created_at" AS t1_r3, "users"."updated_at" AS t1_r4 FROM "posts" LEFT OUTER JOIN "users" ON "users"."id" = "posts"."user_id" /*application='WongnokBlog'*/
=> ["สมชาย", "สมชาย", "สมหญิง", "สมหญิง", "มานะ", "มานะ"]

ประโยคนี้ยาว แต่อ่านแค่สามท่อนก็พอ:

• Post Eager Load — ป้ายหน้าบรรทัดเปลี่ยนจาก Post Load · และมีบรรทัดเดียว ไม่มี User Load ตามมา
• SELECT "posts"."id" AS t0_r0, … "users"."name" AS t1_r1, … — ขอทุกช่องของทั้งสองลิ้นชัก · AS t0_r0 คือตั้งชื่อเล่นให้แต่ละช่อง กันไม่ให้ id ของสองลิ้นชักชนกัน (ไม่ต้องอ่าน)
• FROM "posts" LEFT OUTER JOIN "users" — JOIN = "เอาแฟ้มจากสองลิ้นชักมาวางคู่กันเป็นแผ่นเดียว" · LEFT OUTER = ถึงบทความไหนหาผู้เขียนไม่เจอ ก็ยังเอาบทความนั้นมา (ช่องผู้เขียนว่างไว้)
• ON "users"."id" = "posts"."user_id" — กติกาการจับคู่: "ผู้ใช้เลขที่ … คู่กับบทความที่ช่อง user_id เป็นเลขเดียวกัน"

เทียบกับ Go: GORM ก็มีสองแบบเหมือนกัน · db.Preload("User") = แบบ preload (แยกไปสองรอบ) · db.Joins("User") = แบบ eager_load (เอกสาร GORM เรียกว่า Joins Preloading — ใช้ JOIN ไปรอบเดียว) · ต่างกันที่ GORM ไม่มีตัวที่ "เลือกให้เอง" แบบ includes คุณต้องเลือกเองทุกครั้ง

แล้วเมื่อไหร่ต้องเลือกเอง — ตอนกรองด้วยลิ้นชักลูก

สมมติอยากได้ "บทความของมานะ พร้อมชื่อผู้เขียน" · เงื่อนไข "ชื่อผู้เขียนเป็นมานะ" อยู่ในลิ้นชัก users ไม่ใช่ posts · where(users: { name: "มานะ" }) คือ "เฉพาะแผ่นที่ช่อง name ของลิ้นชัก users เป็นมานะ" · เป็น hash ซ้อน hash: ชั้นนอก users: บอกลิ้นชัก · ชั้นใน { name: "มานะ" } บอกช่องกับค่า

wongnok-blog(dev):005> Post.preload(:user).where(users: { name: "มานะ" }).map(&:title)

  Post Load (1.2ms)  SELECT "posts".* FROM "posts" WHERE "users"."name" = 'มานะ' /*application='WongnokBlog'*/
(wongnok-blog):5:in 'Enumerable#map': PG::UndefinedTable: ERROR:  missing FROM-clause entry for table "users" (ActiveRecord::StatementInvalid)
LINE 1: SELECT "posts".* FROM "posts" WHERE "users"."name" = 'มานะ' ...
                                            ^
…

ใช้ includes แทน — Rails เห็นว่ามีเงื่อนไขของลิ้นชักลูก จึงสลับไปใช้วิธีเย็บติดกัน (Eager Load + JOIN) ให้เอง (ผลจริง · ย่อรายชื่อช่องเป็น …):

wongnok-blog(dev):006> Post.includes(:user).where(users: { name: "มานะ" }).map(&:title)
  Post Eager Load (2.7ms)  SELECT "posts"."id" AS t0_r0, … FROM "posts" LEFT OUTER JOIN "users" ON "users"."id" = "posts"."user_id" WHERE "users"."name" = 'มานะ' /*application='WongnokBlog'*/
=> ["ผัดกะเพราหมูสับ", "แกงเขียวหวานไก่"]

สรุปเป็นตาราง (ผลจริงจาก console ทุกช่อง):

ระวัง to_sql (บท 113 · ดู SQL โดยไม่ยิง): กับ preload และ includes มันโชว์แค่ SQL ของลิ้นชัก posts (ผลจริง) · ไม่เห็นรอบที่สอง ที่ไปหยิบผู้เขียน — อยากรู้ว่าไปตู้กี่รอบจริง ต้องรันแล้วดู log

N+1 ตัวที่สอง: นับคอมเมนต์ด้วย count

ผู้เขียนเป็นแค่ตัวอย่างแรก · ทุกครั้งที่ในลูปมีการถามลิ้นชักอื่น ก็เป็น N+1 ได้หมด · ตัวที่เจอบ่อยมากคือ "บทความนี้มีกี่คอมเมนต์" (สไลด์หน้า 38 · post.comments ใช้ได้เพราะ has_many :comments บท 107) — ผลจริง:

wongnok-blog(dev):001> Post.all.map { |p| p.comments.count }
  Post Load (42.8ms)  SELECT "posts".* FROM "posts" /*application='WongnokBlog'*/
  Comment Count (2.0ms)  SELECT COUNT(*) FROM "comments" WHERE "comments"."post_id" = 1 /*application='WongnokBlog'*/
  Comment Count (1.0ms)  SELECT COUNT(*) FROM "comments" WHERE "comments"."post_id" = 2 /*application='WongnokBlog'*/
  …
  Comment Count (0.9ms)  SELECT COUNT(*) FROM "comments" WHERE "comments"."post_id" = 6 /*application='WongnokBlog'*/
=> [2, 1, 1, 0, 3, 0]

SELECT COUNT(*) FROM "comments" WHERE "comments"."post_id" = 1 = "ไม่ต้องหยิบแฟ้มมา แค่นับว่าในลิ้นชัก comments มีกี่แผ่นที่เป็นของบทความเลขที่ 1" · หน้าตาต่างจาก User Load แต่รูปแบบเดียวกัน: บรรทัดซ้ำ ๆ ต่างกันแค่เลข = 1 + 6

wongnok-blog(dev):002> Post.includes(:comments).map { |p| p.comments.count }

  Post Load (2.6ms)  SELECT "posts".* FROM "posts" /*application='WongnokBlog'*/
  Comment Load (3.2ms)  SELECT "comments".* FROM "comments" WHERE "comments"."post_id" IN (1, 2, 3, 4, 5, 6) /*application='WongnokBlog'*/
  Comment Count (1.6ms)  SELECT COUNT(*) FROM "comments" WHERE "comments"."post_id" = 1 /*application='WongnokBlog'*/
  …
  Comment Count (0.9ms)  SELECT COUNT(*) FROM "comments" WHERE "comments"."post_id" = 6 /*application='WongnokBlog'*/
=> [2, 1, 1, 0, 3, 0]

wongnok-blog(dev):003> Post.includes(:comments).map { |p| p.comments.size }
  Post Load (2.3ms)  SELECT "posts".* FROM "posts" /*application='WongnokBlog'*/
  Comment Load (1.7ms)  SELECT "comments".* FROM "comments" WHERE "comments"."post_id" IN (1, 2, 3, 4, 5, 6) /*application='WongnokBlog'*/
=> [2, 1, 1, 0, 3, 0]

วิธีที่ดีกว่านี้สำหรับ "นับคอมเมนต์" คือให้แฟ้มบทความมีช่องเก็บจำนวนคอมเมนต์ไว้เลย ไม่ต้องนับใหม่ทุกครั้ง — ชื่อ counter_cache อยู่ในบท 116

ข้อมูลเยอะ ๆ: find_each — ยกแฟ้มทีละลัง ไม่ยกทั้งตู้

ปัญหานี้คนละเรื่องกับ N+1 แต่มักเจอคู่กัน · Post.all.each = หยิบแฟ้มทุกแผ่นมากองไว้ในหน่วยความจำ (RAM) ทีเดียว แล้วค่อยวน · 6 แผ่นไม่เป็นไร · สไลด์หน้า 36 ยกตัวอย่าง 2 ล้านแถวบนเครื่อง RAM 2 GB — กองไม่พอ โปรแกรมพัง

find_each วนได้เหมือน each แต่หยิบมาทีละชุด · ลองชุดละ 2 แผ่นกับข้อมูลเรา (ผลจริง):

wongnok-blog(dev):001> Post.find_each(batch_size: 2) { |p| puts p.title }
  Post Load (1.4ms)  SELECT "posts".* FROM "posts" ORDER BY "posts"."id" ASC LIMIT 2 /*application='WongnokBlog'*/
ต้มยำกุ้งน้ำข้น
ส้มตำปูปลาร้า
  Post Load (1.3ms)  SELECT "posts".* FROM "posts" WHERE "posts"."id" > 2 ORDER BY "posts"."id" ASC LIMIT 2 /*application='WongnokBlog'*/
ข้าวมันไก่ประตูน้ำ
ก๋วยเตี๋ยวเรืออยุธยา
  Post Load (0.7ms)  SELECT "posts".* FROM "posts" WHERE "posts"."id" > 4 ORDER BY "posts"."id" ASC LIMIT 2 /*application='WongnokBlog'*/
ผัดกะเพราหมูสับ
แกงเขียวหวานไก่
  Post Load (1.2ms)  SELECT "posts".* FROM "posts" WHERE "posts"."id" > 6 ORDER BY "posts"."id" ASC LIMIT 2 /*application='WongnokBlog'*/
=> nil

• batch_size: 2 — ชุดละ 2 แผ่น (ค่าเริ่มต้นคือ 1000 · ใช้ 2 แค่ให้เห็นกับข้อมูล 6 แผ่น)
• ลัง 1: ORDER BY "posts"."id" ASC LIMIT 2 = "เรียงตามเลขที่น้อยไปมาก เอา 2 แผ่นแรก" → ได้เลขที่ 1, 2
• ลัง 2: WHERE "posts"."id" > 2 … LIMIT 2 = "เลขที่มากกว่า 2 เอามา 2 แผ่น" — จำเลขสุดท้ายของลังก่อน แล้วต่อจากตรงนั้น
• ลังสุดท้าย id > 6 ไม่ได้อะไรกลับมา → รู้ว่าหมดแล้ว จบ · ในหน่วยความจำมีแฟ้มไม่เกิน 2 แผ่นตลอดเวลา
• => nil — ค่าที่ find_each คืนมาเมื่อวนจบ ไม่ต้องสนใจ (ของที่เราอยากเห็นคือชื่อที่ puts พิมพ์ออกมา)

เทียบกับ Go: GORM มี FindInBatches ทำหน้าที่เดียวกัน — db.FindInBatches(&results, 100, func(tx *gorm.DB, batch int) error { … }) = หยิบมาชุดละ 100 แล้วส่งให้ฟังก์ชันของเราทีละชุด

Scoped order is ignored, use :cursor with :order to configure custom order.
  Post Load (1.7ms)  SELECT "posts".* FROM "posts" ORDER BY "posts"."id" ASC LIMIT 2 /*application='WongnokBlog'*/

พี่น้องของมันชื่อ in_batches — แทนที่จะส่งให้ทีละแผ่น มันส่งทั้งลังให้ (เป็นใบเบิกของหนึ่งใบ) · เหมาะกับงานแบบ "แก้ทุกแผ่นในลังนี้ด้วยคำสั่งเดียว" · บทนี้แค่ให้รู้จักชื่อ

ตัวช่วยจับ: strict_loading และ bullet

อ่าน log ทุกหน้าด้วยตาเป็นนิสัยที่ดี แต่คนลืมได้ · Rails จึงมีของที่โวยวายแทนเรา · strict_loading = "บทความชุดนี้ห้ามไปตู้ตอนถามผู้เขียน ถ้าไม่ได้ includes มาก่อน ให้ระเบิดเลย" (ผลจริง):

wongnok-blog(dev):003> post = Post.strict_loading.first
  Post Load (2.5ms)  SELECT "posts".* FROM "posts" ORDER BY "posts"."id" ASC LIMIT 1 /*application='WongnokBlog'*/
=>
#<Post:0x0000000123dc1a58
...
wongnok-blog(dev):004> post.title
=> "ต้มยำกุ้งน้ำข้น"
wongnok-blog(dev):005> post.user
(wongnok-blog):5:in '<main>': `Post` is marked for strict_loading. The User association named `:user` cannot be lazily loaded. (ActiveRecord::StrictLoadingViolationError)
wongnok-blog(dev):006> Post.strict_loading.includes(:user).first.user.name
  Post Load (1.5ms)  SELECT "posts".* FROM "posts" ORDER BY "posts"."id" ASC LIMIT 1 /*application='WongnokBlog'*/
  User Load (0.8ms)  SELECT "users".* FROM "users" WHERE "users"."id" = 1 /*application='WongnokBlog'*/
=> "สมชาย"

• post.title — ปกติ เพราะเป็นช่องบนแฟ้มเอง ไม่ต้องไปตู้
• post.user — error: "บทความนี้ถูกตั้งเป็น strict_loading · ห้ามโหลด :user แบบ lazy (ตอนถาม)" · เจอบรรทัดนี้ = เจอ N+1 ก่อนมันขึ้นเว็บจริง
• บรรทัดสุดท้าย — ใส่ includes(:user) แล้วผ่าน · SQL ของผู้เขียนเป็น = 1 แทน IN (1) เพราะมีบทความแผ่นเดียว ผู้เขียนคนเดียว Rails เลยเขียนแบบสั้น (ความหมายเดียวกัน)

ถ้าอยากให้ model ทั้งตัวเข้มแบบนี้ สไลด์หน้า 36 ใส่ self.strict_loading_by_default = true ไว้ใน class Post (self. ในตัว class = ตั้งค่าให้ทั้ง class ไม่ใช่แฟ้มแผ่นเดียว) · ผมลองตั้งค่าเดียวกันใน console (Post.strict_loading_by_default = true) แล้ว Post.first.user ได้ error ตัวเดียวกันจริง · แต่ระวัง: หน้าเก่าที่ลืม includes จะพังทันที — จะเปิดกับ model ไหน คุยกับทีมก่อน

bullet เป็น gem ที่สไลด์แนะนำ — ระหว่างพัฒนามันคอยดูทุกหน้าแล้วเตือนว่า "หน้านี้มี N+1 ควรเติม includes ตรงนี้" หรือ "includes ตัวนี้ไม่ได้ใช้ ลบได้" · ไม่ได้มากับแอป และบทนี้ไม่ได้ติดตั้ง · ข้อความตัวอย่างจากสไลด์หน้า 36 (ไม่ได้รันในบทนี้): N+1 Query detected · Post => [:user] · Add to your query: .includes([:user]) · ถ้าทีมใช้ อ่านวิธีตั้งค่าที่ github.com/flyerhzm/bullet

นิสัยเดียวที่ต้องติดตัว: เปิด log นับ query ก่อน merge

ทั้งบทสรุปได้ว่า อ่านโค้ดอย่างเดียวไม่มีทางรู้ — post.user กับ post.title หน้าตาเหมือนกัน · count กับ size ได้ผลเท่ากัน · ที่รู้ได้ทุกครั้งคือ log · ก่อนส่งงานหน้าไหนที่โชว์เป็นรายการ ทำ 4 ข้อนี้:

1. เปิดหน้านั้นในเบราว์เซอร์ แล้วดู tail -f log/development.log
2. อ่านบรรทัด Completed … → ดู (N queries, M cached) · ตัวเลขควรไม่โตตามจำนวนแถว (ลองเพิ่มข้อมูลอีกสักแถวแล้วเปิดใหม่ ถ้าตัวเลขขึ้นตาม = N+1)
3. มองหาบรรทัด … Load หรือ … Count ซ้ำ ๆ ต่างกันแค่เลข · ตาม ↳ ไปหาบรรทัดต้นเหตุ (.erb ลบหนึ่ง)
4. แก้ด้วย includes ที่ controller · นับคู่กับ size ไม่ใช่ count · แล้วเปิดหน้าใหม่ นับซ้ำ — อย่าเชื่อว่าแก้แล้วจนกว่า log จะบอก

ข้อนี้สำคัญเป็นพิเศษกับโค้ดที่ AI เขียนให้ · AI ชอบเขียน post.user.name ใน view โดยไม่เติม includes เพราะมันไม่เห็น log ของคุณ · คุณเห็น — แปะ log ให้มันดูแล้วบอกว่า "fix the N+1 in this log" ได้ผลกว่าสั่งลอย ๆ

ถ้าเปิดสไลด์ดูประกอบ

อ้างอิง

• Rails Guides — Active Record Query Interface § N + 1 Queries Problem — อ่านต่อถึง Solution to N + 1 Queries Problem แล้วหยุด · ตัวอย่างในคู่มือเป็นหนังสือ 10 เล่มกับผู้แต่ง ภาพเดียวกับบทความ 6 ชิ้นของเรา
• Rails Guides — § Eager Loading Associations — อ่านหัวข้อย่อย includes · preload · eager_load (ข้ามเรื่อง multiple associations ไปก่อนได้) · ยืนยันว่า includes + where ตารางลูกจะกลายเป็น LEFT OUTER JOIN
• Rails Guides — § Retrieving Multiple Records in Batches — อ่านแค่ find_each กับ option :batch_size · ย่อหน้า "If an order is present in the relation…" ยืนยันว่า order ถูกทิ้งพร้อมคำเตือน (ค่าเริ่มต้น)
• Rails API — ActiveRecord::Batches#find_each — ดูแค่รายการ options · :cursor กับ :order คือสิ่งที่ข้อความ "Scoped order is ignored, use :cursor with :order" ชี้ไป ถ้าวันหนึ่งต้องไล่ด้วยลำดับอื่น
• Rails Guides — § Strict Loading — ยืนยัน strict_loading และ StrictLoadingViolationError · อ่านสั้น ๆ ไม่กี่ย่อหน้า
• Rails Guides — Caching with Rails § SQL Caching — ที่มาของบรรทัด CACHE … Load · อ่านแค่ย่อหน้าแรก: ความจำนี้อยู่แค่ช่วงหนึ่ง request
• GORM — Preloading (Eager Loading) — ฝั่ง Go ที่เทียบกัน · ดูตัวอย่าง Traditional API บรรทัด db.Preload("Orders").Find(&users) ที่ได้ SQL WHERE user_id IN (…) แบบเดียวกับ preload · หัวข้อ Joins Preloading คือแบบ JOIN รอบเดียวที่เทียบกับ eager_load
• GORM — Advanced Query § FindInBatches — ฝั่ง Go ของ find_each · ดูแค่ตัวอย่างแรก (ชุดละ 100)
• GitHub — flyerhzm/bullet — gem ตรวจ N+1 ที่สไลด์แนะนำ (บทนี้ไม่ได้ติดตั้ง) · อ่านแค่ส่วน Configuration ถ้าทีมของคุณใช้