6 أنواع JOIN في SQL يجب أن تعرفها (مع أمثلة بسيطة وواضحة)

لهذا السبب تظهر الانضمامات في كل مكان في التقارير والتحليل:

• بناء تقرير مبيعات يتضمن أسماء العملاء، إجمالي الطلب، وحالة الدفع
• إيجاد العملاء الذين لم يطلبوا بعد
• تدقيق التفاوتات، مثل طلبات بلا مدفوعات
• إنشاء ملخّص “صف واحد لكل عميل” من عدة صفوف متعلقة

بدون الانضمامات، ستضطر لتشغيل استعلامات منفصلة ودمج النتائج يدويًا — بطيء ومعرض للأخطاء وصعب التكرار.

إذا كنت تبني منتجات تعتمد على قاعدة بيانات علاقية (لوحات معلومات، لوحات إدارة، أدوات داخلية، بوابات العملاء)، فالانضمامات هي ما يحول "الجداول الخام" إلى عروض للمستخدمين. حتى أدوات توليد التطبيقات قد تعتمد على أساسيات الانضمام عندما تحتاج صفحات قوائم دقيقة أو واجهات مصالحة بيانات.

أنواع الانضمامات الستة التي ستستخدمها غالبًا

هذا الدليل يركّز على ستة انضمامات تغطي معظم أعمال SQL اليومية:

• INNER JOIN: يعيد فقط الصفوف المتطابقة في كلا الجدولين (مفيد لـ"أرني العلاقات المؤكدة").
• LEFT JOIN: يحتفظ بكل صف من الجدول الأيسر، ويضيف ما يمكن مطابقته من اليمين (مفيد لـ"اشمل البيانات المرتبطة المفقودة").
• RIGHT JOIN: مرآة الـ LEFT JOIN (أقل شيوعًا، لكنه مفيد حسب أسلوب الاستعلام).
• FULL OUTER JOIN: يحتفظ بكل الصفوف من كلا الجدولين، ويطابق عندما يمكن (ممتاز للمطابقة والتدقيق).
• CROSS JOIN: ينتج كل التوافيق الممكنة من الصفوف (مفيد لتوليد تقاويم أو سيناريوهات أو بيانات اختبار — وسهل إساءة استخدامه).
• SELF JOIN: انضمام الجدول إلى نفسه (مفيد للهياكل الهرمية مثل الموظف/المدير).

ملاحظة سريعة عن الصياغة

صياغة JOIN متشابهة عبر قواعد بيانات عديدة (PostgreSQL، MySQL، SQL Server، SQLite). هناك اختلافات قليلة — خاصة حول دعم FULL OUTER JOIN وبعض السلوكيات الحدّية — لكن المفاهيم والأنماط الأساسية قابلة للنقل.

جداول المثال التي سنستخدمها (customers, orders, payments)

لنجعل الأمثلة بسيطة، سنستخدم ثلاث جداول صغيرة تعكس إعدادًا عمليًا: العملاء يضعون طلبات، والطلبات قد (أو قد لا) تحتوي على مدفوعات.

ملاحظة صغيرة قبل البدء: الجداول النموذجية أدناه تظهر بعض الأعمدة فقط، لكن بعض الاستعلامات لاحقًا تشير إلى حقول إضافية (مثل order_date, created_at, status, أو paid_at) لإظهار أنماط شائعة. اعتبر تلك الأعمدة حقول "نمطية" تتواجد غالبًا في مخططات الإنتاج.

1) customers

المفتاح الأساسي: customer_id

2) orders

المفتاح الأساسي: order_id
المفتاح الخارجي: customer_id → customers.customer_id

لاحظ أن order_id = 104 يشير إلى customer_id = 5، وهو غير موجود في customers. هذه الحالة "الغير متطابقة" مفيدة لرؤية سلوك LEFT JOIN وRIGHT JOIN وFULL OUTER JOIN.

3) payments

المفتاح الأساسي: payment_id
المفتاح الخارجي: order_id → orders.order_id

تفصيلان تعليميان مهمان هنا:

• order_id = 102 له صفان للمدفوعات (دفعة مقسمة). عندما تنضم orders إلى payments سيظهر هذا الطلب مرتين — هنا حيث تفاجئ الناس بالتكرارات.
• payment_id = 9004 يشير إلى order_id = 999، الذي لا يوجد في orders. هذا ينشئ حالة "غير متطابقة" أخرى.

ما الذي تتوقعه عند الانضمام بين هذه الجداول

• صفوف مطابقة: مثال، العميل 1 ↔ الطلبات 101/102؛ الطلب 101 ↔ الدفع 9001.
• صفوف غير مطابقة: مثال، العميلان 3 و 4 ليس لديهما طلبات؛ الطلب 104 ليس له عميل؛ الدفع 9004 ليس له طلب.
• تكرارات: انضمام orders إلى payments سيكرر الطلب 102 لأنه لديه مدفوعتان.

INNER JOIN: احتفظ فقط بالصفوف المطابقة

يعيد INNER JOIN الصفوف فقط حيث توجد مطابقة في كلا الجدولين. إذا لم يكن لدى عميل طلبات، فلن يظهر في النتيجة. إذا أشار طلب إلى عميل غير موجود (بيانات خاطئة)، فلن يظهر ذلك الطلب أيضًا.

النمط الأساسي

تختار جدولًا "أيسر" وتُنضم إلى جدول "أيمن" وتربطهما بشرط في جملة ON.

SELECT
  c.customer_id,
  c.name,
  o.order_id,
  o.order_date
FROM customers c
INNER JOIN orders o
  ON o.customer_id = c.customer_id;

الفكرة الأساسية هي سطر ON o.customer_id = c.customer_id: يخبر SQL كيف ترتبط الصفوف.

حالة استخدام واقعية: العملاء الذين قدموا طلبات

إذا أردت قائمة بالعملاء الذين وضعوا فعليًا طلبًا واحدًا على الأقل (وتفاصيل الطلب)، فإن INNER JOIN هو الاختيار الطبيعي:

SELECT
  c.name,
  o.order_id,
  o.total_amount
FROM customers c
INNER JOIN orders o
  ON o.customer_id = c.customer_id
ORDER BY o.order_id;

هذا مفيد لحالات مثل "إرسال رسالة متابعة للطلب" أو "حساب الإيرادات لكل عميل" (حين تهتم فقط بالعملاء الذين لديهم مشتريات).

خطأ شائع: شروط انضمام مفقودة أو غير واضحة

إذا كتبت انضمامًا ونسيت شرط ON (أو انضممت على أعمدة خاطئة)، يمكنك عن غير قصد إنشاء حاصل ديكارتي (كل عميل مع كل طلب) أو إنتاج تطابقات غير صحيحة.

سيئ (لا تفعل هذا):

SELECT c.name, o.order_id
FROM customers c
JOIN orders o;

تأكد دائمًا من وجود شرط انضمام واضح في ON (أو USING في الحالات المناسبة — سنغطي ذلك لاحقًا).

LEFT JOIN: احتفظ بكل شيء من الجدول الأيسر

يعيد LEFT JOIN كل الصفوف من الجدول الأيسر، ويضيف بيانات مطابقة من الجدول الأيمن عند وجودها. إذا لم توجد مطابقة، تظهر أعمدة الجانب الأيمن كـ NULL.

متى تستخدمه

استخدم LEFT JOIN عندما تريد قائمة كاملة من جدولك الأساسي، مع بيانات مرتبطة اختيارية.

مثال: "أرني كل العملاء، وأدرج طلباتهم إن وُجدت."

SELECT
  c.customer_id,
  c.name,
  o.order_id,
  o.order_date
FROM customers c
LEFT JOIN orders o
  ON o.customer_id = c.customer_id
ORDER BY c.customer_id;

• العملاء الذين لديهم طلبات سيظهرون مع تفاصيل الطلب.
• العملاء بدون طلبات ما زالوا يظهرون، لكن o.order_id (وأعمدة orders الأخرى) ستكون NULL.

إيجاد صفوف "بدون تطابق" (النمط الكلاسيكي)

استخدام شائع جدًا لـ LEFT JOIN هو العثور على عناصر ليس لها سجلات مرتبطة.

مثال: "أي العملاء لم يسبق لهم أن طلبوا؟"

SELECT
  c.customer_id,
  c.name
FROM customers c
LEFT JOIN orders o
  ON o.customer_id = c.customer_id
WHERE o.order_id IS NULL;

شرط WHERE ... IS NULL يبقي فقط صفوف جدول اليسار حيث لم يعثر الانضمام على تطابق.

انتبه: المطابقات المتعددة تضاعف الصفوف

يمكن أن "يضاعف" LEFT JOIN صفوف جدول اليسار عندما توجد مطابقات متعددة في الجدول الأيمن.

إذا كان لدى عميل طلبات متعددة، سيظهر العميل مرات متعددة — مرة لكل طلب. هذا متوقع، لكنه قد يفاجئك إذا كنت تحاول عدّ العملاء.

مثال، هذا يحسب الطلبات (ليس العملاء):

SELECT COUNT(*)
FROM customers c
LEFT JOIN orders o
  ON o.customer_id = c.customer_id;

إذا كان هدفك عدّ العملاء فَغالبًا ما تحسب على المفتاح بدلًا من ذلك (مثل COUNT(DISTINCT c.customer_id)), حسب ما تقيس.

RIGHT JOIN: احتفظ بكل شيء من الجدول الأيمن

يحافظ RIGHT JOIN على كل الصفوف من الجدول الأيمن، ويُدرج فقط الصفوف المطابقة من الجدول الأيسر. إذا لم توجد مطابقة، تظهر أعمدة الجدول الأيسر كـ NULL. هو في الأساس صورة معكوسة للـ LEFT JOIN.

مثال بسيط

باستخدام جداولنا، تخيّل أنك تريد سرد كل المدفوعات حتى لو لم تربط بطلب (ربما تم حذف الطلب أو بيانات الدفع فوضوية).

SELECT
  o.order_id,
  o.customer_id,
  p.payment_id,
  p.amount,
  p.paid_at
FROM orders o
RIGHT JOIN payments p
  ON o.order_id = p.order_id;

ما ستحصل عليه:

• كل المدفوعات مدرجة (لأن payments على اليمين).
• إذا لم يكن لدى دفعة طلب مطابق، ستكون أعمدة o.order_id و o.customer_id قيمتها NULL.

نفس الاستعلام كـ LEFT JOIN (غالبًا مفضل)

غالبًا يمكنك إعادة كتابة RIGHT JOIN كـ LEFT JOIN عبر تبديل ترتيب الجداول:

SELECT
  o.order_id,
  o.customer_id,
  p.payment_id,
  p.amount,
  p.paid_at
FROM payments p
LEFT JOIN orders o
  ON o.order_id = p.order_id;

يعطي نفس النتيجة، لكن كثيرًا ما يجد الناس أنه أسهل للقراءة: تبدأ بالجدول "الرئيسي" (payments) ثم تسحب البيانات الاختيارية.

قابلية القراءة: لماذا يتجنب الكثيرون RIGHT JOIN

تمنع إرشادات أسلوب SQL استخدام RIGHT JOIN لأن القارئ يُجبَر على قلب نمط التفكير الاعتيادي:

• "ابدأ بالجدول الرئيسي"
• "LEFT JOIN الجداول الإضافية"

عندما تُكتب العلاقات الاختيارية دائمًا كـ LEFT JOIN تصبح الاستعلامات أسهل للمسح.

متى قد يكون RIGHT JOIN مفيدًا

قد يكون مفيدًا عند تعديل استعلام موجود وتكتشف أن الجدول الذي يجب الحفاظ عليه موجود على اليمين. بدل إعادة كتابة الاستعلام الطويل، تغيير انضمام واحد إلى RIGHT JOIN قد يكون تعديلًا سريعًا وآمنًا.

FULL OUTER JOIN: احتفظ بكل الصفوف من كلا الجدولين

يعيد FULL OUTER JOIN كل الصفوف من كلا الجدولين.

• إذا تطابقت صفوف على مفتاح الانضمام، تحصل على صف مركب واحد (مثل INNER JOIN).
• إذا كان الصف موجودًا فقط على اليسار، يظهر مع NULL لعمود اليمين.
• إذا كان الصف موجودًا فقط على اليمين، يظهر مع NULL لعمود اليسار.

متى يكون مفيدًا

حالة عمل كلاسيكية هي مصالحة الطلبات مقابل المدفوعات:

• تريد رؤية الطلبات المدفوعة (مطابقات)
• الطلبات غير المدفوعة (طلب موجود، دفع مفقود)
• المدفوعات الشاردة (دفع موجود لكن لا يوجد طلب — خطأ بيانات، استرداد، مرجع خاطئ، إلخ)

مثال:

SELECT
  o.order_id,
  o.customer_id,
  p.payment_id,
  p.amount
FROM orders o
FULL OUTER JOIN payments p
  ON p.order_id = o.order_id;

دعم قواعد البيانات (من يمكنه تشغيله مباشرة)

FULL OUTER JOIN مدعوم في PostgreSQL، SQL Server، وOracle.

هو غير متاح في MySQL وSQLite (ستحتاج إلى حلول بديلة).

بديل محمول: جمع LEFT JOIN و RIGHT JOIN عبر UNION

إذا لم تدعم قاعدة بياناتك FULL OUTER JOIN، يمكنك محاكاتها بدمج:

1. كل صفوف orders (مع المدفوعات المطابقة إن وُجدت)، و
2. كل صفوف payments التي لم تطابق أي طلب.

نمط شائع:

SELECT o.order_id, o.customer_id, p.payment_id, p.amount
FROM orders o
LEFT JOIN payments p
  ON p.order_id = o.order_id

UNION

SELECT o.order_id, o.customer_id, p.payment_id, p.amount
FROM orders o
RIGHT JOIN payments p
  ON p.order_id = o.order_id;

نصيحة: عندما ترى NULLs على أحد الجانبين، فهذه إشارة إلى أن الصف كان "مفقودًا" في الجدول الآخر — بالضبط ما تريده للمراجعات والتسويات.

CROSS JOIN: اصنع كل التوافيق (استخدمه بحذر)

يعيد CROSS JOIN كل الأزواج الممكنة من الصفوف بين جدولين. إذا كان لدى الجدول A ثلاث صفوف والجدول B أربعة صفوف، ستكون النتيجة 3 × 4 = 12 صفًا. يُسمَّى هذا أيضًا حاصل ديكارتي.

هذا قد يبدو مخيفًا — ويمكن أن يكون كذلك — لكنه مفيد عندما تريد فعلاً توليد التوافيق.

مثال صغير وآمن: المقاسات × الألوان (بناء SKU)

تخيل أن خيارات المنتج مخزنة في جداول منفصلة:

• sizes: S, M, L
• colors: Red, Blue

يستطيع CROSS JOIN توليد كل المتغيرات الممكنة (مفيد لإنشاء رموز المخزون، تحضير كتالوج، أو للاختبار):

SELECT
  s.size,
  c.color
FROM sizes AS s
CROSS JOIN colors AS c;

النتيجة (3 × 2 = 6 صفوف):

• S / Red
• S / Blue
• M / Red
• M / Blue
• L / Red
• L / Blue

التحذير الكبير: النتائج تنمو بسرعة

لأن أحجام الصفوف تُضرب، يمكن أن ينفجر حجم CROSS JOIN بسرعة:

• 10,000 عملاء × 50 منتج = 500,000 صف
• 100,000 × 100,000 = 10,000,000,000 صف

قد يبطئ ذلك الاستعلامات ويستهلك الذاكرة وينتج مخرجات لا فائدة لها. إذا احتجت توليد التوافيق، اجعل الجداول المدخلة صغيرة واعتبر إضافة قيود أو حدود بشكل متحكم.

SELF JOIN: انضمم بالجدول إلى نفسه

الـ SELF JOIN هو تمامًا ما يبدو عليه: تنضم إلى نفس الجدول. هذا مفيد عندما يرتبط صف بصف آخر داخل نفس الجدول — غالبًا في علاقات الوالد/الابن مثل الموظفون ومديروهم.

لماذا تحتاج أسماء مستعارة (aliases) وكيف تساعد

بما أنك تستخدم نفس الجدول مرتين، يجب أن تُعطي كل "نسخة" اسمًا مستعارًا مختلفًا. الأسماء المستعارة تجعل الاستعلام قابلًا للقراءة وتُحدد لأي جانب تشير.

نمط شائع:

• e للموظف
• m للمدير

مثال عملي: الموظفون ومديروهم

تخيل جدول employees يحتوي على:

• id
• name
• manager_id (يشير إلى id لموظف آخر)

لإدراج كل موظف مع اسم مديره:

SELECT
  e.id,
  e.name AS employee_name,
  m.name AS manager_name
FROM employees e
LEFT JOIN employees m
  ON e.manager_id = m.id;

التعامل مع الموظفين في القمة (NULL في manager_id)

لاحظ أن الاستعلام يستخدم LEFT JOIN، وليس INNER JOIN. هذا مهم لأن بعض الموظفين قد لا يكون لهم مدير (مثل المدير التنفيذي). في تلك الحالات، يكون manager_id غالبًا NULL، وانضمام LEFT يحافظ على صف الموظف مع إظهار manager_name كـ NULL.

لو استخدمت INNER JOIN لكان أولئك الموظفون ذوو NULL في manager_id قد اختفوا من النتيجة.

شروط الانضمام: ON مقابل USING (ولماذا يهم)

الانضمام لا "يعرف" تلقائيًا كيف ترتبط الجداول — عليك أن تخبره. علاقة الانضمام تُعرّف في شرط الانضمام، ويجب أن توضع بجانب جملة JOIN لأنها تشرح كيف تتطابق الجداول، ليس كيف تريد ترشيح النتيجة النهائية.

ON: الأكثر مرونة (والأشهر)

استخدم ON عندما تريد تحكمًا كاملاً في منطق المطابقة — أسماء أعمدة مختلفة، شروط متعددة، أو قواعد إضافية.

SELECT
  c.customer_id,
  c.name,
  o.order_id,
  o.created_at
FROM customers AS c
INNER JOIN orders AS o
  ON o.customer_id = c.customer_id;

ON هو المكان الذي يمكنك فيه تعريف مطابقات أكثر تعقيدًا (مثال: المطابقة على عمودين) دون أن تتحول الاستعلامات إلى لعبة تخمين.

USING: أقصر، لكنه لعمود باسم مشترك فقط

بعض قواعد البيانات (مثل PostgreSQL و MySQL) تدعم USING. هي اختصار مريح عندما يحتوي كلا الجدولين على عمود بنفس الاسم وتريد الانضمام على ذلك العمود.

SELECT
  customer_id,
  name,
  order_id
FROM customers
JOIN orders
USING (customer_id);

فائدة أنيقة: USING عادةً يعيد عمود customer_id واحدًا في الإخراج بدلاً من نسختين.

تجنَّب أسماء الأعمدة المبهمة: فضِّل التأهيل في الانضمامات

بعد الانضمام، تتداخل أسماء الأعمدة غالبًا (id, created_at, status). إذا كتبت SELECT id قد ترمي قاعدة البيانات خطأ "عمود غامض" — أو الأسوأ، قد تقرأ الـ id الخاطئ.

فضّل بادئات الجدول (أو الأسماء المستعارة) للوضوح:

SELECT c.customer_id, o.order_id
FROM customers AS c
JOIN orders AS o
  ON o.customer_id = c.customer_id;

تجنّب SELECT * في الاستعلامات المنضمة

SELECT * يصبح فوضويًا بسرعة مع الانضمامات: تسحب أعمدة غير ضرورية، وتخاطر بأسماء مكررة، وتجعل من الصعب رؤية ماذا ينتج الاستعلام.

بدلًا من ذلك، اختر الأعمدة التي تحتاجها بالتحديد. نتيجتك أنظف، أسهل صيانة، وغالبًا أكثر كفاءة — خصوصًا عندما تكون الجداول عريضة.

تصفية البيانات المُنضمة: WHERE مقابل ON

عند الانضمام، كل من WHERE و ON يبدوان كأنهما "يرشيحان"، لكن توقيتهما مختلف.

• ON يحدد أي الصفوف تتطابق أثناء الانضمام.
• WHERE يصف أي الصفوف تُبقى بعد تكوّن النتيجة النهائية.

ذلك الفرق في التوقيت هو سبب تحوّل LEFT JOIN عن غير قصد إلى INNER JOIN.

كيف يكسر WHERE انضمام LEFT عن طريق الخطأ

افترض أنك تريد كل العملاء حتى أولئك الذين ليس لديهم طلبات مدفوعة حديثة:

SELECT c.customer_id, c.name, o.order_id, o.status, o.order_date
FROM customers c
LEFT JOIN orders o
  ON o.customer_id = c.customer_id
WHERE o.status = 'PAID'
  AND o.order_date >= DATE '2025-01-01';

المشكلة: للعملاء الذين ليس لديهم أي طلب مطابق، ستكون قيم o.status و o.order_date هي NULL. شرط WHERE يرفض تلك الصفوف، لذا يختفي العملاء غير المطابقين — فيصبح LEFT JOIN وكأنه INNER JOIN.

انقل شروط الانضمام إلى ON للاحتفاظ بالصفوف غير المطابقة

SELECT c.customer_id, c.name, o.order_id, o.status, o.order_date
FROM customers c
LEFT JOIN orders o
  ON o.customer_id = c.customer_id
 AND o.status = 'PAID'
 AND o.order_date >= DATE '2025-01-01';

الآن يظل العملاء الذين ليس لديهم طلبات مؤهلة ظاهرين (مع أعمدة طلب قيمتها NULL) — وهذا عادة ما يكون الهدف من LEFT JOIN.

قائمة سريعة: ما الذي ينتمي في ON مقابل WHERE؟

• ضع الشروط في ON عندما تصف أي صفوف من الجدول الأيمن مسموح لها أن تتطابق (فلترة الحالة/التاريخ/النوع على الجدول المنضم).
• ضع الشروط في WHERE عندما تصف أي الصفوف النهائية تريد الاحتفاظ بها (فلترة على جدول اليسار، أو عندما تتعمد أن تطلب وجود تطابق).
• إذا كنت تريد "الاحتفاظ بكل صفوف اليسار لكن تقييد صفوف اليمين" فَفضّل LEFT JOIN + شروط في ON.
• إذا قصدت فعلاً "الصفوف التي لها تطابق فقط" فاستخدم INNER JOIN (أو WHERE o.order_id IS NOT NULL صراحةً).

تجنب الصفوف المكررة ومفاجآت العلاقات متعددة-إلى-متعددة

الانضمامات لا تضيف أعمدة فقط — يمكنها أيضًا تضاعف الصفوف. هذا سلوك صحيح غالبًا، لكنه يفاجئ عندما تتغير الإجماليات.

لماذا تتضاعف الصفوف

يعيد الانضمام صف إخراج لكل زوج من الصفوف المطابقة.

• واحد-لكثير: عميل واحد قد يكون له عدة طلبات. إذا انضممت customers إلى orders، قد يظهر العميل عدة مرات — مرة لكل طلب.
• كثير-إلى-كثير (الفخ الحقيقي): إذا انضممت orders إلى payments وكل طلب قد له دفعات متعددة، فستحصل على عدة صفوف لكل طلب. وإذا انضممت أيضًا إلى جدول "عناصر الطلب" (order_items)، قد تنشأ ظاهرة الضرب (payments × items) لكل طلب.

التلخيص المسبق قبل الانضمام

إذا هدفك "صف واحد لكل عميل" أو "صف واحد لكل طلب" فلخص الجانب "الكثير" أولًا، ثم انضم.

-- One row per order from payments
WITH payment_totals AS (
  SELECT
    order_id,
    SUM(amount) AS total_paid,
    COUNT(*)   AS payment_count
  FROM payments
  GROUP BY order_id
)
SELECT
  o.order_id,
  o.customer_id,
  COALESCE(pt.total_paid, 0) AS total_paid,
  COALESCE(pt.payment_count, 0) AS payment_count
FROM orders o
LEFT JOIN payment_totals pt
  ON pt.order_id = o.order_id;

هذا يحافظ على شكل الانضمام المتوقع: صف واحد لكل طلب يظل صفًا واحدًا.

DISTINCT كحل أخير

SELECT DISTINCT قد يجعل التكرارات "تبدو" مصححة، لكنه قد يخفي المشكلة الحقيقية:

• قد يحذف صفوفًا صحيحة بصمت.
• قد يخفي شرط انضمام خاطئ (مثل فقدان جزء من مفتاح مركب).
• قد يفسد المجاميع (SUM، COUNT) إذا لم تفهم سبب التكرار.

استخدمه فقط عندما تكون متأكدًا أن التكرارات عرضية وتعرف سببها.

فحص أمني سريع: تحقق من العدّات

قبل الوثوق في النتائج، قارن عدّات الصفوف:

• عِد صفوف جدولك الرئيسي (مثلاً، orders).
• عد صفوف بعد الانضمام.
• إذا زاد العدد بشكل غير متوقع، افحص أي مفاتيح تسبب مطابقة متعددة وقرر هل تحتاج تلخيصًا مسبقًا أو مسار انضمام مختلف.

أساسيات الأداء وخلاصة سريعة للانضمامات

غالبًا ما تُلام الانضمامات على "بطء الاستعلامات"، لكن السبب الحقيقي عادةً هو كمية البيانات التي تطلب من قاعدة البيانات دمجها، ومدى سهولة إيجاد الصفوف المطابقة.

الفهرسة (مفاهيميًا) ولماذا تُحسّن الانضمامات

فكر في الفهرس مثل فهرس كتاب. بدونه قد تضطر قاعدة البيانات لمسح الكثير من الصفوف للعثور على المطابقات. بوجود فهرس على مفتاح الانضمام (مثلاً customers.customer_id و orders.customer_id) يمكن لقارئ قاعدة البيانات القفز إلى الصفوف ذات الصلة بسرعة.

إذا كان عمود يُستخدم كثيرًا للمطابقة، فهو مرشح جيد للفهرسة.

انضم على مفاتيح ثابتة (لا أسماء أو بريد إلكتروني)

عند الإمكان، انضم على معرفات فريدة ومستقرة:

• جيد: customers.customer_id = orders.customer_id
• محفوف بالمخاطر: customers.email = orders.email أو customers.name = orders.name

الأسماء تتغير وقد تتكرر؛ الإيميلات قد تتغير أو تختلف بالصياغة. المعرفات مُصممة للمطابقة الثابتة وغالبًا ما تكون مفهرسة.

قلل العمل مبكرًا

عادتاان بسيطتان تُسرّع الانضمامات بشكل ملحوظ:

1. اختر أعمدة أقل. تجنّب SELECT * عند الانضمام.
2. قيد الصفوف قبل أو أثناء الانضمام. صفِّ البيانات بقدر المعقول في البداية.

مثال: قيّد الطلبات أولًا ثم انضم:

SELECT c.customer_id, c.name, o.order_id, o.created_at
FROM customers c
JOIN (
  SELECT order_id, customer_id, created_at
  FROM orders
  WHERE created_at >= DATE '2025-01-01'
) o
  ON o.customer_id = c.customer_id;

إذا كنت تطوّر هذه الاستعلامات داخل تطبيق (مثلاً صفحة تقرير تعتمد على PostgreSQL)، يمكن لأدوات توليد الكود أن تسرع بناء البنية التحتية بينما تظل أنت متحكمًا في منطق الانضمام الذي يضمن الصحة.

خلاصة سريعة للـ JOIN

• INNER JOIN → فقط الصفوف المطابقة في كلا الجدولين
• LEFT JOIN → كل صفوف الجدول الأيسر، بالإضافة إلى المطابقات من اليمين (NULL عند عدم وجودها)
• RIGHT JOIN → كل صفوف الجدول الأيمن، بالإضافة إلى المطابقات من اليسار (NULL عند عدم وجودها)
• FULL OUTER JOIN → كل الصفوف من كلا الجدولين؛ المطابقات تندمج، وغير المطابقات تظهر كـ NULL
• CROSS JOIN → كل التوافيق الممكنة من الصفوف (الحجم يتضاعف؛ استخدمه بحذر)
• SELF JOIN → جدول ينضم إلى نفسه (مفيد للهياكل الهرمية والمقارنات)