كيف يتجنب `select_related` و `prefetch_related` مشكلة N+1؟

Question

Accepted Answer

مشكلة **استعلام N+1** هي أكثر مشاكل أداء Django ORM شيوعاً: الوصول إلى الكائنات المرتبطة في حلقة يؤدي إلى استعلام منفصل للقاعدة البيانات لكل واحد منها. يحل **`select_related`** و **`prefetch_related`** المشكلة بجلب البيانات المرتبطة بكفاءة — فهي أدوات تحسين أداء أساسية.

## مشكلة 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` يؤدي إلى استعلام كسول للقاعدة البيانات مرة أخرى. مع 100 كتاب، هذا يعني 101 استعلام — وهو قاتل أداء حاد وخفي يظهر غالباً فقط مع أحجام البيانات الحقيقية.

## 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` ينفذ **JOIN** SQL لجلب الكائن المرتبط (أو الكائنات) في *نفس* الاستعلام. استخدمه للعلاقات **ForeignKey الأمامية و OneToOne** (كائن مرتبط واحد)، حيث يكون JOIN فعالاً.

## prefetch_related — للعلاقات ManyToMany / العلاقات العكسية (استعلام منفصل)

```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` ينفذ **استعلام منفصل** للكائنات المرتبطة ويدمجها في Python. استخدمه للعلاقات **ManyToMany والعلاقات العكسية** (كائنات مرتبطة متعددة)، حيث يؤدي 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 هي **أكثر المشاكل الأداء شيوعاً وتأثيراً في تطبيقات Django**، وفهم `select_related`/`prefetch_related` ضروري لكتابة كود فعال من حيث الأداء.

المشكلة خطيرة لأن الصيغة الملائمة للـ ORM التي تجعل الوصول إلى الكائنات المرتبطة سهلاً جداً (`book.author.name`) تؤدي بصمت إلى استعلام قاعدة بيانات في كل مرة — الكود الذي يعمل بشكل جيد مع عدد قليل من السجلات يتدهور بشكل فادح مع أحجام البيانات الحقيقية (100 سجل → 101 استعلام)، ويُكتشف غالباً فقط في الإنتاج تحت الحمل.

هذان الأداتان هما الحل الأساسي المعياري: **`select_related`** يستخدم SQL JOIN لجلب العلاقات الأمامية ForeignKey/OneToOne في استعلام واحد، في حين **`prefetch_related`** يستخدم استعلام منفصل (مدمج في Python) للعلاقات ManyToMany/العكسية حيث سيكون JOIN غير فعال — وحساب **أيهما يُستخدم لأي نوع علاقة** هو المهارة الأساسية.

إتقانهما يحول مئات الاستعلامات إلى واحد أو اثنين، مما يحسّن أداء الصفحة بشكل ملحوظ غالباً.

هذا التحسين أساسي جداً بحيث أن التعرف على مشاكل N+1 (باستخدام أدوات مثل Django Debug Toolbar لاكتشاف عد الاستعلامات المفرطة) وتطبيق الإصلاح الصحيح هي كفاءة أساسية تميز المطورين الذين يكتبون كود Django فعال من حيث الأداء عن أولئك الذين تتباطأ تطبيقاتهم مع نمو البيانات.

كما أنها من بين أكثر مواضيع مقابلات Django التي يتم اختبارها بشكل متكرر، تحديداً لأنها تعكس فهماً عملياً وحرجاً من حيث الأداء للـ ORM.