select_related와 prefetch_related는 어떻게 N+1 문제를 방지하나요?

Question

Accepted Answer

**N+1 쿼리 문제**는 가장 흔한 Django ORM 성능 이슈입니다: 반복문에서 관련 객체에 접근하면 각각에 대해 별도의 데이터베이스 쿼리가 발생합니다. **`select_related`**와 **`prefetch_related`**는 관련 데이터를 효율적으로 가져와 이를 해결합니다. 필수적인 최적화 도구입니다.

## N+1 문제

```python
# ❌ N+1 쿼리
books = Book.objects.all()              # 쿼리 1: 모든 book 가져오기
for book in books:
    print(book.author.name)             # book마다 +1 쿼리로 author 가져오기!
# book 100개 → 1 + 100 = 101 쿼리(끔찍한 성능)
```

각 `book.author` 접근은 데이터베이스를 다시 지연 쿼리합니다. book이 100개면 101개의 쿼리가 됩니다. 심각하고 은밀한 성능 저하 요인으로, 종종 실제 데이터 양에서만 드러납니다.

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

```python
# ✅ JOIN으로 하나의 쿼리
books = Book.objects.select_related("author").all()
for book in books:
    print(book.author.name)             # 추가 쿼리 없음 — author가 JOIN됨
# book 100개 → 총 1 쿼리
```

`select_related`는 SQL **JOIN**을 수행하여 *같은* 쿼리에서 관련 객체를 가져옵니다. **정방향 ForeignKey와 OneToOne** 관계(단일 관련 객체)에 사용하며, JOIN이 효율적입니다.

## prefetch_related — ManyToMany / 역방향 FK용(별도 쿼리)

```python
# ✅ 총 두 개의 쿼리(N+1 아님)
authors = Author.objects.prefetch_related("books").all()
for author in authors:
    for book in author.books.all():     # 추가 쿼리 없음 — book이 prefetch됨
        print(book.title)
# 쿼리 1: 모든 author; 쿼리 2: 그들의 모든 book → Django가 Python에서 조인
```

`prefetch_related`는 관련 객체에 대해 **별도의 쿼리**를 실행하고 Python에서 조인합니다. **ManyToMany와 역방향 ForeignKey** 관계(여러 관련 객체)에 사용하며, JOIN이 행을 비효율적으로 증가시킬 경우에 적합합니다.

## 어느 것을 사용할까

```text
select_related   → ForeignKey, OneToOne(정방향, 단일 객체) → SQL JOIN, 1 쿼리
prefetch_related → ManyToMany, 역방향 ForeignKey(여러 객체) → 2 쿼리, Python에서 조인
결합하고 체이닝할 수 있으며, 관계를 가로지를 수 있음:
  Book.objects.select_related("author").prefetch_related("tags")
  Book.objects.select_related("author__publisher")   # 다단계
```

## N+1 문제 탐지

```text
✓ Django Debug Toolbar — 페이지당 쿼리 수를 보여줌(N+1을 시각적으로 포착)
✓ django-silk, 또는 쿼리 로깅(connection.queries)으로 개수 세기
→ 페이지가 수백 개의 유사한 쿼리를 실행하면 N+1일 가능성이 높음.
```

## 왜 중요한가

N+1 쿼리 문제는 Django 애플리케이션에서 **가장 흔하고 영향이 큰 단일 성능 이슈**이며, `select_related`/`prefetch_related`를 이해하는 것은 성능 좋은 코드를 작성하는 데 필수적입니다.

이 문제가 교활한 이유는 관련 객체에 접근하기 쉽게 만드는 편리한 ORM 문법(`book.author.name`)이 매번 조용히 데이터베이스 쿼리를 유발하기 때문입니다. 적은 레코드에서는 잘 동작하는 코드가 실제 데이터 양에서 파국적으로 저하되며(레코드 100개 → 쿼리 101개), 종종 부하가 걸린 production에서만 발견됩니다.

이 두 도구는 표준적이고 필수적인 해결책입니다: **`select_related`**는 SQL JOIN을 사용해 정방향 ForeignKey/OneToOne 관계를 단일 쿼리로 가져오고, **`prefetch_related`**는 JOIN이 비효율적일 ManyToMany/역방향 ForeignKey 관계에 별도 쿼리(Python에서 조인)를 사용합니다. 그리고 **어느 관계 타입에 어느 것을 사용할지** 아는 것이 핵심 기술입니다.

이를 숙달하면 수백 개의 쿼리가 한두 개로 바뀌어 종종 페이지 성능이 극적으로 개선됩니다.

이 최적화는 매우 기초적이어서, N+1 문제를 인식하고(Django Debug Toolbar 같은 도구로 과도한 쿼리 수 포착) 올바른 해결책을 적용하는 것은 효율적인 Django 코드를 작성하는 개발자와 데이터가 늘어나면서 앱이 기어가게 만드는 개발자를 구분하는 핵심 역량입니다.

또한 실용적이고 성능에 중요한 ORM 이해를 반영하기 때문에 가장 자주 출제되는 Django 면접 주제 중 하나입니다.