N+1 Query للمبتدئ: ليه dashboard بياخد 8 ثواني والحل في سطر ORM

الحل: prefetch بسطر واحد

الـ prefetch_related بيخلي Django يجمع كل الـ user_ids من نتيجة الـ query الأول، بعدين يبعت query واحد بس للـ orders فيه WHERE user_id IN (1, 2, 3, ...)، وبعدين يعمل الربط بين الـ users والـ orders جوّا الـ Python نفسه. أنت ربحت 49 رحلة round-trip.

نفس الفكرة في باقي الـ ORMs

الأرقام الحقيقية

قياس فعلي على PostgreSQL 16 على instance بحجم db.t3.medium (2 vCPU، 4GB RAM)، جدول users فيه 500K صف وجدول orders فيه 12M صف، والـ app server في نفس الـ region:

• قبل (51 query): 1,840ms متوسط، 2,340ms في الـ P95.
• بعد (2 query): 38ms متوسط، 62ms في الـ P95.
• التحسّن: 48× في الـ P50، 37× في الـ P95.

الفرق الحقيقي مش في زمن الـ query نفسه — هو في عدد الـ round-trips على الشبكة. كل round-trip معاه TCP overhead و connection acquire من الـ pool.

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

1. الذاكرة في الـ app server: prefetch بيجيب كل الـ orders للـ 50 user. لو في user عنده 100,000 order، Python هيلف على 5 مليون صف في الذاكرة علشان يحسب رقم واحد. الحل: annotate(orders_count=Count('orders')) في Django خلّي الـ DB تحسبلك الـ count بدل ما تجيب الصفوف نفسها.
2. الـ filter الضيق: لو بتجيب 5 users فقط، الفرق بين 6 query و 2 query مش هيبان. ميتساويش وقتك في refactor.
3. الـ Cross-AZ latency: لو الـ DB في availability zone مختلفة عن الـ app (شائع جداً في AWS)، كل round-trip بيكلّفك 1-4ms زيادة شبكة. هنا الـ N+1 بيبقى أسوأ بكتير، والـ prefetch بيكون مكسب أكبر.
4. الـ over-fetching: لو بتعرض 3 columns بس بس prefetch بيجيب الـ relation كاملة بكل أعمدتها، أنت بتجيب data زيادة. استخدم only() أو select_related بحكمة.

متى لا تستخدم prefetch

الـ prefetch بيكون كارثة في الحالات دي:

• علاقة one-to-many ضخمة جداً: user عنده مليون order. هتقتل الذاكرة. استخدم annotate أو aggregated view أو denormalized counter في الـ user model نفسه.
• محتاج top 3 من كل علاقة: الـ prefetch بيجيب الكل. استخدم Prefetch مع queryset مخصّص أو LATERAL JOIN في raw SQL.
• الـ relation chain طويلة: user.orders.items.product.category. كل مستوى prefetch بيضاعف الذاكرة. غالباً GraphQL DataLoader أو denormalization أفضل.

إزاي تكتشف N+1 في مشروعك دلوقتي

1. Django: django-debug-toolbar بيعرضلك عدد الـ queries في كل request مع الـ SQL نفسه.
2. Rails: bullet gem بيطبع warning تلقائي لو لقى N+1.
3. Laravel: laravel-debugbar أو beyondcode/laravel-query-detector.
4. Prisma / Node: فعّل log: ['query'] في الـ client وشوف اللي بيتبعت.
5. على مستوى الـ DB: الـ extension pg_stat_statements في PostgreSQL بيعرضلك أكتر الـ queries تكراراً. لو شفت query شبيه بـ SELECT * FROM orders WHERE user_id = $1 متنفّذ 50,000 مرة، عندك N+1.

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

افتح أبطأ صفحة في تطبيقك دلوقتي. شغّل query logger من القائمة فوق. لو شفت 20+ query في request واحد على نفس الـ table، عندك N+1 مستخفي. ضيف prefetch_related (أو includes / with / include حسب الـ ORM)، اعمل reload للصفحة، اعيد القياس. لو نزل الزمن أكتر من 5×، مبروك، انت لقيت bottleneck حقيقي بسطر كود واحد.

مصادر

• Django Documentation — prefetch_related and select_related.
• Ruby on Rails Guides — Eager Loading Associations.
• Prisma Docs — Relation Queries (include).
• Laravel Documentation — Eloquent: Eager Loading.
• PostgreSQL Documentation — pg_stat_statements.
• Markus Winand — Use The Index, Luke! (مرجع شامل لأداء الـ joins والـ indexes).