N+1 Queries للمتوسط: ليه ORM بيعمل 201 query في طلب واحد

الكود اللي بيولّد المشكلة (Django مثالًا):

الحل في كلمة واحدة:

الفرق بين الأداتين مهم جدًا:

• select_related: لعلاقات ForeignKey و OneToOne. بيعمل SQL JOIN واحد. أنسب لما العلاقة "to-one".
• prefetch_related: لعلاقات ManyToMany و reverse ForeignKey. بيعمل query إضافي واحد بـ WHERE IN (...) ويربط النتائج في Python. أنسب لما العلاقة "to-many".

في Laravel: Product::with('category')->take(200)->get(). في Rails: Product.includes(:category).limit(200). في Sequelize: { include: [Category] }. الفكرة واحدة في كل ORM، الاسم بس بيختلف.

قياس فعلي من إنتاج

على جدول Product بـ 50,000 صف وعلاقة ForeignKey لـ Category، endpoint بيرجّع 200 منتج بـ pagination على PostgreSQL 16:

• قبل (N+1): 201 query، 4,180ms متوسط، 22MB استهلاك ذاكرة في Django process.
• بعد (select_related): 1 query، 78ms متوسط، 18MB ذاكرة.

التحسّن: 53× أسرع. ده مش رقم نظري، ده قياس مباشر من production logs بعد تطبيق الإصلاح على endpoint قائمة المنتجات في e-commerce بـ 8000 طلب/دقيقة.

الـ trade-offs اللي محدش بيحكي عنها

select_related بـ JOIN بيرجّع كل أعمدة الجدولين في كل صف. لو المنتج فيه 30 عمود والتصنيف فيه 15، كل صف فيه 45 خانة بيانات × 200 منتج = 9000 خانة بتعدي على الشبكة. لو الـ Category فيه عمود JSON كبير بيخزّن مثلًا تفاصيل localization بميجا، ممكن JOIN يبقى أبطأ من 2 query منفصلة.

الحل: ضيف only() أو defer() علشان تجيب الأعمدة المطلوبة فقط:

المكسب من select_related صريح: 53× سرعة. التكلفة: 5 دقايق فهم العلاقات + سطر إضافي. بتكسب: latency أقل، استهلاك CPU أقل على DB. بتخسر: لو نسيت only هتنقل بيانات أكتر من اللازم على الشبكة.

متى لا تستخدم هذه الطريقة

1. لو الـ endpoint بيرجّع صف واحد فقط، N+1 مش موجود من الأساس. مفيش داعي لـ select_related.

2. لو العلاقة nested 4 مستويات وكل مستوى فيه جداول كبيرة، الـ JOIN ممكن يولّد cartesian explosion ملايين الصفوف. في الحالة دي استخدم prefetch_related مع Prefetch() object للتحكم الدقيق.

3. لو بتستخدم async ORM (مثل Tortoise أو SQLAlchemy 2.0 async)، الـ syntax مختلف ولازم تتأكد من selectinload بدل joinedload في غالب الحالات.

4. لو في cache layer قبل الـ DB (Redis مثلًا) بياكل 95% من الـ requests، حل N+1 ممكن يبقى أولوية أقل من تحسين hit rate الـ cache نفسه.

الخطوة التالية

افتح أبطأ endpoint في الـ API بتاعك دلوقتي، فعّل django-debug-toolbar أو ما يعادلها في الـ stack بتاعك، وعد الـ queries في request واحد. لو لقيت أكتر من 5 queries على list endpoint بسيط، عندك N+1. ضيف select_related أو prefetch_related حسب نوع العلاقة، وأعد القياس فورًا. أبسط 5 دقايق هتدّيك أكبر مكسب أداء في الشهر ده.

المصادر

• Django Documentation — QuerySet API: select_related & prefetch_related (docs.djangoproject.com).
• PostgreSQL Documentation — pg_stat_statements module (postgresql.org/docs/current/pgstatstatements.html).
• Bill Karwin — SQL Antipatterns (Pragmatic Bookshelf، 2010)، الفصل الخاص بـ N+1.
• Laravel Documentation — Eager Loading (laravel.com/docs/eloquent-relationships).
• Rails Guides — Active Record Query Interface (guides.rubyonrails.org/active_record_querying.html).
• Google SRE Book — Chapter 6, Monitoring Distributed Systems (sre.google/sre-book).