select_related และ prefetch_related หลีกเลี่ยงปัญหา N+1 อย่างไร?

Question

Accepted Answer

**ปัญหา N+1 query** เป็นปัญหาด้านประสิทธิภาพของ Django ORM ที่พบบ่อยที่สุด: การเข้าถึง object ที่เกี่ยวข้องในลูปทำให้เกิด query แยกต่างหากต่อ object แต่ละตัว **`select_related`** และ **`prefetch_related`** แก้ปัญหานี้ด้วยการดึงข้อมูลที่เกี่ยวข้องอย่างมีประสิทธิภาพ — เป็นเครื่องมือ optimize ที่จำเป็น

## ปัญหา N+1

```python
# ❌ N+1 queries
books = Book.objects.all()              # 1 query: fetch all books
for book in books:
    print(book.author.name)             # +1 query PER book to fetch its author!
# 100 books → 1 + 100 = 101 queries (terrible performance)
```

การเข้าถึง `book.author` แต่ละครั้งจะ query database ใหม่แบบ lazy ด้วยหนังสือ 100 เล่ม นั่นคือ 101 query — เป็นตัวฆ่าประสิทธิภาพที่รุนแรงและแอบแฝง ซึ่งมักโผล่ขึ้นมาเมื่อมีปริมาณข้อมูลจริงเท่านั้น

## select_related — สำหรับ ForeignKey / OneToOne (SQL JOIN)

```python
# ✅ ONE query with a JOIN
books = Book.objects.select_related("author").all()
for book in books:
    print(book.author.name)             # NO extra queries — author was JOINed in
# 100 books → 1 query total
```

`select_related` ทำ SQL **JOIN** เพื่อดึง object ที่เกี่ยวข้องใน query *เดียวกัน* ใช้มันสำหรับความสัมพันธ์ **forward ForeignKey และ OneToOne** (object ที่เกี่ยวข้องตัวเดียว) ที่การ JOIN มีประสิทธิภาพ

## prefetch_related — สำหรับ ManyToMany / reverse FK (query แยก)

```python
# ✅ TWO queries total (not N+1)
authors = Author.objects.prefetch_related("books").all()
for author in authors:
    for book in author.books.all():     # NO extra queries — books were prefetched
        print(book.title)
# query 1: all authors; query 2: all their books → Django joins them in Python
```

`prefetch_related` รัน **query แยกต่างหาก** สำหรับ object ที่เกี่ยวข้องและรวมพวกมันใน Python ใช้มันสำหรับความสัมพันธ์ **ManyToMany และ reverse ForeignKey** (object ที่เกี่ยวข้องหลายตัว) ที่การ JOIN จะเพิ่มจำนวนแถวอย่างไม่มีประสิทธิภาพ

## ควรใช้อันไหน

```text
select_related   → ForeignKey, OneToOne (forward, single object) → SQL JOIN, 1 query
prefetch_related → ManyToMany, reverse ForeignKey (many objects) → 2 queries, joined in Python
You can combine and chain them, and span relationships:
  Book.objects.select_related("author").prefetch_related("tags")
  Book.objects.select_related("author__publisher")   # multi-level
```

## การตรวจจับปัญหา N+1

```text
✓ Django Debug Toolbar — shows the query count per page (spot N+1 visually)
✓ django-silk, or logging queries (connection.queries) to count them
→ If a page runs hundreds of similar queries, you likely have an N+1.
```

## ทำไมจึงสำคัญ

ปัญหา N+1 query เป็น**ปัญหาด้านประสิทธิภาพที่พบบ่อยและส่งผลกระทบมากที่สุด**ใน Django application และการเข้าใจ `select_related`/`prefetch_related` เป็นสิ่งจำเป็นในการเขียนโค้ดที่มีประสิทธิภาพ

ปัญหานี้แอบแฝงเพราะ syntax ของ ORM ที่สะดวกซึ่งทำให้การเข้าถึง object ที่เกี่ยวข้องง่ายมาก (`book.author.name`) จะแอบทำให้เกิด query database ทุกครั้ง — โค้ดที่ทำงานได้ดีกับ record ไม่กี่ตัวจะเสื่อมลงอย่างหายนะเมื่อมีปริมาณข้อมูลจริง (100 record → 101 query) ซึ่งมักถูกค้นพบใน production ภายใต้ load เท่านั้น

เครื่องมือสองตัวนี้เป็นทางออกมาตรฐานที่จำเป็น: **`select_related`** ใช้ SQL JOIN เพื่อดึงความสัมพันธ์ forward ForeignKey/OneToOne ใน query เดียว ขณะที่ **`prefetch_related`** ใช้ query แยก (รวมใน Python) สำหรับความสัมพันธ์ ManyToMany/reverse-ForeignKey ที่การ JOIN จะไม่มีประสิทธิภาพ — และการรู้ว่า**ควรใช้อันไหนกับความสัมพันธ์ประเภทใด**เป็นทักษะสำคัญ

การเชี่ยวชาญพวกมันเปลี่ยน query หลายร้อยตัวให้เหลือหนึ่งหรือสอง ซึ่งมักปรับปรุงประสิทธิภาพของหน้าได้อย่างมาก

การ optimize นี้พื้นฐานมากจนการตระหนักถึงปัญหา N+1 (โดยใช้เครื่องมือเช่น Django Debug Toolbar เพื่อตรวจหาจำนวน query ที่มากเกินไป) และการใช้วิธีแก้ที่ถูกต้องเป็นความสามารถหลักที่แยกนักพัฒนาที่เขียนโค้ด Django ที่มีประสิทธิภาพออกจากผู้ที่แอปของพวกเขาช้าลงจนคืบคลานเมื่อข้อมูลเติบโต

มันยังเป็นหนึ่งในหัวข้อสัมภาษณ์ Django ที่ถูกถามบ่อยที่สุด เพราะมันสะท้อนความเข้าใจ ORM ที่ใช้จริงและสำคัญต่อประสิทธิภาพ