select_related và prefetch_related tránh vấn đề N+1 như thế nào?

Question

Accepted Answer

**Vấn đề truy vấn N+1** là vấn đề hiệu năng ORM phổ biến nhất của Django: truy cập các đối tượng liên quan trong một vòng lặp kích hoạt một truy vấn database riêng cho từng cái. **`select_related`** và **`prefetch_related`** giải quyết nó bằng cách lấy dữ liệu liên quan một cách hiệu quả — chúng là các công cụ tối ưu thiết yếu.

## Vấn đề N+1

```python
# ❌ N+1 truy vấn
books = Book.objects.all()              # 1 truy vấn: lấy tất cả book
for book in books:
    print(book.author.name)             # +1 truy vấn MỖI book để lấy author của nó!
# 100 book → 1 + 100 = 101 truy vấn (hiệu năng tệ hại)
```

Mỗi lần truy cập `book.author` lại truy vấn database một cách lazy. Với 100 book, đó là 101 truy vấn — một kẻ giết hiệu năng nghiêm trọng, lén lút thường chỉ lộ ra khi có khối lượng dữ liệu thực.

## select_related — cho ForeignKey / OneToOne (SQL JOIN)

```python
# ✅ MỘT truy vấn với một JOIN
books = Book.objects.select_related("author").all()
for book in books:
    print(book.author.name)             # KHÔNG có truy vấn thêm — author đã được JOIN
# 100 book → tổng cộng 1 truy vấn
```

`select_related` thực hiện một **JOIN** SQL để lấy (các) đối tượng liên quan trong *cùng* một truy vấn. Dùng nó cho quan hệ **ForeignKey chiều xuôi và OneToOne** (một đối tượng liên quan), nơi một JOIN là hiệu quả.

## prefetch_related — cho ManyToMany / FK ngược (truy vấn riêng)

```python
# ✅ tổng cộng HAI truy vấn (không phải N+1)
authors = Author.objects.prefetch_related("books").all()
for author in authors:
    for book in author.books.all():     # KHÔNG có truy vấn thêm — book đã được prefetch
        print(book.title)
# truy vấn 1: tất cả author; truy vấn 2: tất cả book của họ → Django ghép chúng trong Python
```

`prefetch_related` chạy một **truy vấn riêng** cho các đối tượng liên quan và ghép chúng trong Python. Dùng nó cho quan hệ **ManyToMany và ForeignKey ngược** (nhiều đối tượng liên quan), nơi một JOIN sẽ nhân số hàng lên một cách kém hiệu quả.

## Dùng cái nào

```text
select_related   → ForeignKey, OneToOne (chiều xuôi, một đối tượng) → SQL JOIN, 1 truy vấn
prefetch_related → ManyToMany, ForeignKey ngược (nhiều đối tượng) → 2 truy vấn, ghép trong Python
Bạn có thể kết hợp và nối chuỗi chúng, và bắc qua các quan hệ:
  Book.objects.select_related("author").prefetch_related("tags")
  Book.objects.select_related("author__publisher")   # nhiều cấp
```

## Phát hiện vấn đề N+1

```text
✓ Django Debug Toolbar — hiển thị số truy vấn mỗi trang (phát hiện N+1 trực quan)
✓ django-silk, hoặc ghi log truy vấn (connection.queries) để đếm chúng
→ Nếu một trang chạy hàng trăm truy vấn tương tự, bạn có lẽ đang gặp N+1.
```

## Tại sao điều này quan trọng

Vấn đề truy vấn N+1 là **vấn đề hiệu năng phổ biến và có tác động nhất** trong các ứng dụng Django, và hiểu `select_related`/`prefetch_related` là thiết yếu để viết mã hiệu năng cao.

Vấn đề này nguy hiểm vì cú pháp ORM tiện lợi khiến việc truy cập đối tượng liên quan dễ dàng (`book.author.name`) lại lặng lẽ kích hoạt một truy vấn database mỗi lần — mã chạy ổn với vài bản ghi suy thoái thảm khốc với khối lượng dữ liệu thực (100 bản ghi → 101 truy vấn), thường chỉ được phát hiện trong production dưới tải.

Hai công cụ này là giải pháp tiêu chuẩn, thiết yếu: **`select_related`** dùng một JOIN SQL để lấy quan hệ ForeignKey/OneToOne chiều xuôi trong một truy vấn duy nhất, trong khi **`prefetch_related`** dùng một truy vấn riêng (ghép trong Python) cho quan hệ ManyToMany/ForeignKey ngược nơi một JOIN sẽ kém hiệu quả — và biết **dùng cái nào cho loại quan hệ nào** là kỹ năng then chốt.

Nắm vững chúng biến hàng trăm truy vấn thành một hoặc hai, thường cải thiện hiệu năng trang một cách đáng kể.

Tối ưu này cơ bản đến mức nhận diện vấn đề N+1 (dùng công cụ như Django Debug Toolbar để phát hiện số truy vấn dư thừa) và áp dụng đúng cách sửa là một năng lực cốt lõi phân biệt các lập trình viên viết mã Django hiệu quả với những người mà app chậm dần khi dữ liệu tăng.

Nó cũng nằm trong số các chủ đề phỏng vấn Django được hỏi thường xuyên nhất, chính vì nó phản ánh hiểu biết ORM thực tế, quan trọng về hiệu năng.