ال استعلامات SQL سيئة الصياغة هذه من أكثر الأسباب شيوعاً لبطء أداء التطبيقات عند التعامل مع قواعد بيانات علائقية ضخمة مثل MySQL وPostgreSQL وSQL Server وOracle وDB2. ورغم توفر خوادم قوية وسحابات مرنة، إلا أن الاستعلامات غير الفعالة ستؤدي في النهاية إلى خسائر. ارتفاع تكاليف البنية التحتية، وزيادة زمن الاستجابة، وتجربة مستخدم أسوأ.
إن تحسين استعلامات SQL في قواعد البيانات الكبيرة يتجاوز بكثير مجرد "إضافة فهرس وانتهى الأمر". إنه ينطوي على فهم كيفية تفكير مُحسِّن الاستعلامكيفية تخزين البيانات، وأنماط الوصول التي يستخدمها تطبيقك، والتقنيات المُدمجة التي تُتيح لك تقليل استخدام الإدخال/الإخراج، ووحدة المعالجة المركزية، والذاكرة. في الأقسام التالية، سنستعرض، بتفصيل كبير مع أمثلة، أكثر الاستراتيجيات فعالية لتحقيق أقصى استفادة من قواعد البيانات العلائقية.
ما هو تحسين استعلامات SQL في الواقع، ولماذا هو مهم؟
تحسين استعلام SQL هذا يعني إعادة كتابته (وتعديل سياقه: الفهارس، والإحصائيات، والتصميم) بحيث يُعيد المحرك نفس النتيجة مع استهلاك موارد أقل وفي وقت أقصر. يسمح بناء جملة SQL بالعديد من الطرق للتعبير عن نفس الشيء، ولكن لا يتم تنفيذ جميعها بنفس السرعة، خاصةً عندما يكون هناك ملايين الصفوف أو عمليات الربط المعقدة.
عندما يفهم المطور كيفية عملها مخطط الاستعلام باستخدام محركك (PostgreSQL، MySQL، SQL Server، Oracle، DB2، إلخ)، يمكنك كتابة استعلامات تستخدم الفهارس بشكل أفضل، وتقلل من عمليات القراءة غير الضرورية، وتقلل من العمليات المكلفة مثل الفرز، أو عمليات المسح التسلسلي، أو الاستعلامات الفرعية المتكررة المرتبطة.
ومع ذلك، من المهم توضيح أن تحسين الاستعلام ليس العامل الوحيد المؤثر في الأداءيؤثر تصميم المخطط (التطبيع، المفاتيح الأساسية والأجنبية، أنواع البيانات)، والبنية (النسخ المتماثلة، والأقسام، وذاكرة التخزين المؤقت)، والبنية التحتية نفسها تأثيرًا كبيرًا. ولكن حتى مع وجود بنية جيدة، قد يُشكل استعلام واحد غير مُحسَّن مشكلة كبيرة. عنق زجاجة وحشي.
من بين مزايا العمل في مجال الاستشارات، تبرز المزايا التالية: تحسين الأداء العام (معالجة المزيد من الطلبات في وقت أقل)، خفض تكلفة الحوسبة السحابية (استهلاك أقل لوحدة المعالجة المركزية والقرص، وأحجام أصغر للمثيلات) و تجربة مستخدم أكثر سلاسة من خلال تقليل أوقات الانتظار في قوائم المنتجات وعمليات البحث والتقارير. علاوة على ذلك، فإن الاستعلامات الواضحة والمنظمة جيدًا هي أسهل في الصيانة وتصحيح الأخطاءوهو أمر يحظى بتقدير كبير عندما يتوسع المشروع.
في التطبيقات التي تهدف حقًا إلى التوسع، يصبح تحسين الاستعلام المستمر مهمة متكررة: مراقبة، كشف، قياس، ضبط، وإعادة قياسإنها ليست عملية لمرة واحدة، بل هي عملية مستمرة.
مثال عملي: نفس الاستعلام، أداء مختلف تمامًا
لتحويل أفكارك إلى واقع ملموس، تخيل طاولة طلبات تضم أكثر من 20 مليون سجل في موقع للتجارة الإلكترونية، نريد استرجاع طلبات العميل المكتملة خلال الثلاثين يومًا الماضية، وبدون تفكير عميق، يمكننا كتابة شيء كهذا:
SELECT * FROM pedidos
WHERE cliente_id = 456
AND LOWER(estado) = 'completado'
AND fecha_creacion BETWEEN NOW() - INTERVAL '30 days' AND NOW();
هذا الاستعلام يُعيد ما نريده، لكن من وجهة نظر الأداء، فهو فوضوي بعض الشيء: فهو يستخدم تحديد *، يطبق دالة (LOWER) على عمود تصفية، ويجمع التواريخ بتعبيرات قد تتعارض مع استخدام الفهارس. وإذا لم تكن هناك فهارس مناسبة على معرّف العميل أو الحالة أو تاريخ الإنشاء، سيُجبر المحرك على مسح جزء كبير من الجدول.
النتائج العملية واضحة: تم نقل بيانات أكثر من اللازمالمزيد من العمل للخلفية لتعيين الأعمدة غير المستخدمة، والكثير من قراءة القرص، ووقت التنفيذ الذي يمكن أن يرتفع إلى عدة ثوانٍ في الجداول الكبيرة جدًا، مما يؤثر على النظام بأكمله عند تشغيله عدة مرات.
يمكن صياغة السؤال نفسه بطريقة أكثر ذكاءً على النحو التالي:
SELECT id, fecha_creacion, total
FROM pedidos
WHERE cliente_id = 456
AND estado = 'Completado'
AND fecha_creacion >= CURRENT_DATE - INTERVAL '30 days'
ORDER BY fecha_creacion DESC
LIMIT 100;
نحن هنا اختيار الأعمدة الضرورية فقطتجنب استخدام الدوال في عمود الحالة، وتبسيط شرط التاريخ، والحد من عدد الصفوف. مع فهارس مصممة جيدًا (على سبيل المثال، INDEX(cliente_id, fecha_creacion) وواحد عن estado (إذا كان عدد عناصره كبيرًا)، يمكن للمحرك استخدام عمليات مسح الفهرس وحل الاستعلام في أجزاء من الثانية بدلاً من الثواني.
يوضح هذا التباين فكرة رئيسية: لا يكفي أن "يعمل" الاستعلام.عليك أن تقلق بشأن كيفية سير الأمور عندما لا يحتوي الجدول على مئات الصفوف، بل على ملايين.
الفهارس: الأداة الرئيسية لتسريع عمليات البحث
الكثير تُعد الفهارس الأداة الأقوى لتسريع الاستعلامات في قواعد البيانات الكبيرة. بدلاً من اجتياز الجدول بأكمله صفًا صفًا (المسح التسلسلي أو مسح التسلسل), يستخدم المحرك هياكل مساعدة (عادةً ما تكون أشجار B أو أشجار R أو جداول التجزئة، اعتمادًا على نوع البيانات والمحرك) تسمح بالانتقال مباشرة إلى الصفوف المرشحة.
في MySQL، على سبيل المثال، أكثر البنى شيوعًا هي الأشجار ب بالنسبة لفهارس الأنواع PRIMARY KEY, UNIQUE, INDEX y FULLTEXTبينما تستخدم المؤشرات المكانية أشجار R ويمكن للجداول الموجودة في الذاكرة سحب البيانات من الفهارس بناءً على مزيجتم تحسين كل منها لنمط وصول محدد.
لكن الأمر لا يتعلق بوضع فهرس على كل شيء. كل فهرس إضافي إنه يشغل مساحة على القرص ويبطئ عمليات الإضافة والتحديث والحذف.لأن المحرك يجب أن يحافظ على تزامن الهيكل. تكمن الحيلة في إيجاد التوازن بين عدد المؤشرات ووقت الاستجابة، مع التركيز على استفسارات القراءة النقدية.
من بين أكثر أنواع الفهارس شيوعًا في محركات قواعد البيانات العلائقية نجد تلك الخاصة بـ المفتاح الأساسي (تحديد كل صف بشكل فريد وعدم السماح بالقيم الفارغة)، تلك الخاصة بـ مفتاح خارجي (بالإشارة إلى المفتاح الأساسي لجدول آخر)، مؤشرات فريدة (يضمن التفرد، ولكنه يسمح بالقيم الفارغة) و المؤشرات المركبة على عدة أعمدة، وهو أمر مفيد للغاية عند التصفية أو الفرز حسب أكثر من حقل واحد في وقت واحد.
وهناك أيضاً سيناريوهات يكون فيها استخدام مؤشرات ذات قيم متكررة (لتسريع عمليات البحث في الأعمدة غير الفريدة) أو فهارس النصوص الكاملة (FULLTEXT في MySQL، على سبيل المثال) لتحسين عمليات البحث في حقول النصوص الطويلة. منذ إصدار MySQL 8.0.13، يمكن إنشاء هذه الحقول. المؤشرات الوظيفيةأي بناءً على نتيجة تعبير أو دالة (على سبيل المثال، YEAR(fecha_pago))، مما يفتح الباب أمام التحسينات المتقدمة.
يمكننا إنشاء فهارس في MySQL باستخدام عبارات مختلفة: CREATE INDEX، وإضافتها لاحقاً؛ ALTER TABLEلتعديل جدول موجود؛ أو مباشرة في التعريف باستخدام CREATE TABLEفي الحالات الثلاث جميعها، يُسمح بالفهارس البسيطة والمركبة والفريدة والبادئة (فقط الأحرف N الأولى من a VARCHAR) أو FULLTEXT، وذلك حسب التصميم الذي نحتاجه.
استخدام مؤشرات البادئة يُعدّ هذا مفيدًا عند التعامل مع سلاسل نصية طويلة، حيث يكفي عدد قليل نسبيًا من الأحرف لتمييز جميع القيم تقريبًا. بهذه الطريقة، نقلل حجم الفهارس دون فقدان الكثير من الانتقائية، وهو أمر بالغ الأهمية في أعمدة مثل أسماء العملاء، حيث يمكننا فهرسة أول 25 حرفًا، على سبيل المثال، بدلًا من الحقل بأكمله.
حدد الأعمدة التي تحتاجها فقط
إساءة تحديد * إنها إحدى أكثر العادات السيئة شيوعاً في لغة SQL. تكون مريحة أثناء التطوير، لكنها تصبح عبئاً في بيئة الإنتاج. كل عمود إضافي يعني المزيد من البايتات التي تنتقل من قاعدة البيانات يعتمد ذلك على تطبيقك، ويتطلب المزيد من الذاكرة على جهاز العميل والمزيد من عمليات إلغاء التسلسل.
عندما يحتوي جدول على أعمدة كبيرة (مثل كائنات BLOB، وملفات JSON كبيرة، وملفات نصية ضخمة، وصور رمزية ثنائية، وما إلى ذلك)، فإن تضمينها يزيد من عمليات الإدخال/الإخراج واستهلاك ذاكرة الوصول العشوائي (RAM) دون داعٍ. علاوة على ذلك، في محركات قواعد البيانات مثل PostgreSQL، يُحسّن تقليل عدد الأعمدة من الأداء. فهرس فقط مسح ضوئي، حيث تستجيب قاعدة البيانات من الفهرس دون اللجوء إلى الكومة، ولكن هذا لا يعمل إلا إذا كانت جميع الأعمدة التي تطلبها موجودة في الفهرس.
مثال كلاسيكي: طاولة users مع أعمدة مثل المعرف، البريد الإلكتروني، تجزئة كلمة المرور، الصورة الرمزية، تاريخ الإنشاء، آخر تسجيل دخولإذا رميت SELECT * FROM users WHERE email = 'juan@example.com';ستحصل على تجزئة كلمة المرور والصورة الرمزية الثنائية حتى لو كنت ترغب فقط في عرض البريد الإلكتروني وتاريخ آخر تسجيل دخول. من الأفضل بكثير أن تطلب ذلك مباشرةً. id, email, last_login.
اعمل دائمًا مع قوائم الأعمدة الصريحة يجعل استعلاماتك أكثر وضوحًا، ويحميك من تغييرات المخطط (إضافة عمود لا تُسبب أي مشاكل)، ويقلل بشكل كبير من استهلاك الموارد في الجداول الكبيرة أو القوائم المُقسّمة إلى صفحات، مما يُساعد على إدارة كميات كبيرة من البيانات.
عمليات الربط والاستعلامات الفرعية وعبارات CTE: كيفية هيكلة الاستعلامات المعقدة بشكل صحيح
ال الاستعلامات الفرعية المترابطة قد تبدو الاستعلامات التي تُنفذ مرة واحدة لكل صف في الاستعلام الخارجي أنيقة نظريًا، لكنها عمليًا تُصبح عائقًا أمام الأداء مع ازدياد حجم الجداول. فكل صف في الجدول الرئيسي يُفعّل تنفيذًا إضافيًا للاستعلام الفرعي، مما ينتج عنه عدد هائل من العمليات.
كلما أمكن ذلك، يُفضل تحويل هذه الاستعلامات الفرعية إلى عمليات الربط المفهرسة جيدًا س و تعابير الجداول المشتركة (CTEs) يُقسّم هذا المنطق إلى خطوات واضحة. عادةً ما يتعامل مُحسِّن الاستعلامات مع مجموعة من الجداول بشكل أفضل بكثير من تعامله مع مجموعة من الاستعلامات الفرعية المعقدة.
على سبيل المثال، للحصول على المنتجات مع اسم فئتها، بدلاً من إجراء استعلام فرعي في SELECT من الأفضل استخدام JOIN مقابل جدول الفئات. إذا كانت أعمدة الربط مفهرسة (على سبيل المثال، productos.categoria_id y categorias.id)، يمكن للمحرك حل عملية الربط بتكلفة منخفضة للغاية حتى على الجداول الكبيرة.
ال CTEs (WITH ... AS (...)تُعدّ هذه الأدوات مفيدةً للغاية في إعداد تقارير الاستعلامات، وعمليات التجميع المعقدة، والمنطق التدريجي. ورغم أنها لا تُحسّن الأداء دائمًا بمفردها، إلا أنها تُساعد مُخطِّط الاستعلام، والأهم من ذلك، تُحسّن من سهولة قراءة الاستعلام، مما يُسهّل إجراء المزيد من التحسينات، مثل إضافة فهارس مُحدّدة أو تخزين النتائج الوسيطة.
الترقيم والحدود للتحكم في الأحجام الكبيرة
في التطبيقات العملية، نادراً ما يكون عرض آلاف الصفوف دفعة واحدة أمراً منطقياً من منظور تجربة المستخدم. فعادةً ما يتم استهلاك قائمة المنتجات أو سجل الطلبات أو سجل الأحداث صفحةً تلو الأخرى، لذا حدد عدد الصفوف المُعادة إنه شرط أساسي للتسلق.
يستخدم النهج الكلاسيكي LIMIT y OFFSET (على سبيل المثال ، LIMIT 10 OFFSET 20 للانتقال إلى الصفحة "الثالثة"). من السهل تنفيذه وفهمه، ولكنه يعاني من مشكلة خطيرة: يجب على المحرك أن قم باجتياز جميع الصفوف السابقة لـ OFFSET بنفس الطريقة.على الرغم من أنها لا تُرجع سوى آخر 10 عناصر. في الجداول الكبيرة جدًا، تؤدي قيم OFFSET العالية إلى أوقات استجابة أسوأ بشكل متزايد.
عند التعامل مع مئات الآلاف أو ملايين الصفوف، من الأفضل عادةً أن ترقيم الصفحات باستخدام مفاتيح الاختصار أو الترقيم القائم على البحثفي هذا النهج، بدلاً من إخبار قاعدة البيانات "بتجاوز 1000 صف"، فإنك تخبرها "بإرجاع السجلات N التالية بدءًا من قيمة المفتاح المصنفة هذه"، باستخدام شروط من النوع WHERE fecha_creacion < <última_fecha_vista> مع ORDER BY ثابتة.
تتيح هذه التقنية للمحرك الاستفادة من فهرس مباشر على العمود المصنف (على سبيل المثال، fecha_creacion o idمما يجنب تكلفة التنقل بين الصفحات الوسيطة. علاوة على ذلك، فإنه يجعل ترقيم الصفحات أسهل. مقاوم للإضافات أو الحذف بين الصفحات، وهو أمر لا يضمنه نظام الإزاحة.
في المقابل، فإن ترقيم الصفحات باستخدام مجموعة المفاتيح له عيب يتمثل في أن ليس من السهل الانتقال إلى الصفحة 37 بدون معلومات إضافية، حيث يعمل النظام بشكل تصاعدي انطلاقاً من مؤشر منطقي (آخر معرّف أو تاريخ تم استرجاعه). ولهذا السبب، تجمع العديد من الأنظمة بين كلا النهجين حسب الاحتياجات الوظيفية.
تجنب استخدام الدوال في الأعمدة المُفلترة، واستخدم عبارة WHERE بشكل جيد.
يُعد تطبيق أحد المصادر الشائعة جدًا لانخفاض الأداء مصدرًا لانخفاض الأداء. وظائف على الأعمدة التي تشارك في عوامل التصفيةتعابير مثل LOWER(nombre), DATE(fecha) o CAST(campo AS ...) ضمن البند WHERE عادة ما تمنع هذه القيود المُحسِّن من استخدام فهرس ذلك العمود.
بل من الأفضل قم بتطبيع البيانات عند إدخالها أو تحديثها (على سبيل المثال، حفظ رسائل البريد الإلكتروني بأحرف صغيرة، والحالات بتشفير متجانس) وتحويل قيم الإدخال لتتوافق مع هذا التنسيق، بدلاً من تطبيق الوظيفة على العمود في كل مقارنة.
يجدر أيضاً الانتباه إلى البند نفسه. WHERE لجعلها انتقائية قدر الإمكان. على الرغم من أن ترتيب الشروط لا يؤثر دائمًا بشكل مباشر (عادةً ما يعيد المُحسِّن ترتيبها)، إلا أنه من المفيد وجودها. مسندات مفهرسة جيدًا ومقارنات بسيطة بدلاً من الأنماط المكلفة مثل LIKE '%texto'الأمر الذي يستدعي عادةً إجراء فحص كامل.
عندما تحتاج إلى إزالة العناصر المكررة، فكّر فيما إذا كان DISTINCT أو إذا كان من الممكن إعادة تصميم الاستعلام باستخدام JOINs قيود أكثر دقة أو قيودًا على التفرد في النموذج. كلاهما DISTINCT كما UNION عادة ما تتضمن عمليات الفرز أو التجميعوالتي تُعد من بين أغلى البنود في خطة التنفيذ.
الحفاظ على المؤشرات والإحصائيات لمساعدة المُحسِّن
تعتمد محركات قواعد البيانات الحديثة على الإحصاءات الداخلية لتقدير عدد الصفوف التي تستوفي كل شرط، وتحديد الفهارس الأنسب، وترتيب ربط الجداول. إذا كانت هذه الإحصائيات قديمة، فقد يتخذ المجدول قرارات سيئة للغاية وينتج عنه خطط تنفيذ غير فعالة.
لذلك من المهم تشغيل أوامر مثل ANALYZE (أو متغيراتها المحددة في كل محرك) لـ تحديث الإحصائيات بعد عمليات التحميل الكبيرةالهجرات أو الأحجام الكبيرة من INSERT, UPDATE y DELETEفي PostgreSQL، على سبيل المثال، تتم معالجة autovacuum عادةً تلقائيًا، ولكن بعد استيراد ملف كبير، قد يكون من المفيد تشغيله. ANALYZE كتيب.
في MySQL لدينا عبارات مثل ANALYZE TABLE، الذي يقوم بتحليل وتخزين توزيع المفاتيح لمساعدة المُحسِّن على تحديد ترتيب واستخدام الفهارس في JOINsبالإضافة إلى ذلك، OPTIMIZE TABLE سماح إلغاء تجزئة الجداول، وإعادة ترتيب الفهارس وتحديثها، وهو أمر موصى به في الجداول التي خضعت للعديد من التغييرات.
للتأكد من أن المحرك يستخدم المؤشرات كما هو متوقع، لا يوجد شيء أفضل من سحب البيانات من EXPLAIN o EXPLAIN ANALYZEتُظهر لنا هذه الأدوات الخطة المُقدَّرة (وفي بعض المحركات، تُظهر أيضًا الخطة الفعلية مع أوقات القراءة وعدد الصفوف المقروءة) وتُشير إلى ما إذا كان يتم إجراء مسح تسلسلي (ALL (في MySQL، على سبيل المثال) أو إذا كان Index Scanكم عدد الصفوف المتوقعة وكم عدد الصفوف التي يتم لعبها فعلياً.
ربما يكون تعلم قراءة هذه الخطط أحد أهم المهارات لأي شخص يرغب في تحسين قواعد البيانات: يتيح لك ذلك اكتشاف الاختناقات والفهارس غير المفيدة والمرشحات الانتقائية الضعيفة وعمليات الربط غير المرتبة بشكل جيد. قبل وقت طويل من وصول المشكلة إلى مرحلة الإنتاج.
فهارس النصوص الكاملة، والتعبيرات النمطية، والسيناريوهات الخاصة
عندما تعمل مع حقول نصية كبيرة (الأوصاف، ومحتوى HTML الغني، والتعليقات، وما إلى ذلك)، عمليات البحث باستخدام LIKE '%palabra%' سرعان ما تصبح هذه الأساليب غير عملية للجداول الكبيرة. في هذه الحالات، توفر محركات مثل MySQL فهارس من نوع FULLTEXT والمشغلين مثل MATCH() AGAINST()مما يسمح بإجراء عمليات بحث أكثر كفاءة وملاءمة.
مع FULLTEXT يمكنك الاختيار بين أوضاع مختلفة: لغة طبيعية, منطقي (مع المشغلين) +, -, *(علامات اقتباس للعبارات الدقيقة، وما إلى ذلك) أو توسيع الاستعلام لتوسيع نطاق النتائج ذات الصلة. يتيح لك هذا إنشاء محركات بحث داخلية قوية للغاية دون الحاجة إلى مغادرة قاعدة البيانات.
توجد سيناريوهات أكثر تعقيدًا حيث يتضمن النص، على سبيل المثال، وسوم HTML مضمنة. في هذه الحالة، قد يكون من الضروري دمج فهرس. FULLTEXT مع وظائف مثل REGEXP_REPLACE لتنقية التصنيفات عند مقارنة العبارات المتطابقة. تتمثل إحدى الاستراتيجيات الشائعة في قم بالتصفية أولاً باستخدام فهرس النص الكامل ثم قم بتطبيق التعبير النمطي في شرط ثانٍ لتضييق نطاق النتيجة إلى الكمية الدقيقة دون مسح الجدول بأكمله.
تسمح محركات أخرى، مثل أوراكل، باستخدام تعبيرات الجداول العادية تساعد هذه الميزات مُحسِّن الاستعلامات على إدراج الشروط داخل العروض وتقليل حجم البيانات الوسيطة بأسرع وقت ممكن. يُعد هذا الأسلوب مفيدًا للغاية عند العمل مع العديد من العروض المتداخلة أو التعريفات المعقدة في بيئات العمل التعاونية.
أفضل الممارسات الإضافية: المعلمات، والعروض المادية، وتقسيم الاستعلام
إلى جانب المؤشرات وخطط التنفيذ، هناك عدد من الممارسات الجيدة الشاملة والتي تساهم في كل من الأداء والسلامة. ومن أهمها استخدم الاستعلامات المُعَلَّمة بدلاً من دمج السلاسل النصية لإنشاء SQL ديناميكي، فإن هذا يقلل من خطر حقن SQL ويسمح لقاعدة البيانات بإعادة استخدام خطط التنفيذ للاستعلامات ذات البنية نفسها.
في الأنظمة ذات استفسارات ثقيلة ومتكررة للغاية (لوحات المعلومات، والتقارير التنفيذية، والحسابات الإجمالية)، مناظر مادية إنها حليف عظيم. على عكس العرض العادي، فإنها تخزن نتيجة الاستعلام فعليًا، لتصبح نوعًا من الجداول المحسوبة مسبقًا والتي يمكن فهرستها والاستعلام عنها بسرعة كبيرة.
تدعم قواعد بيانات PostgreSQL وOracle وSQL Server (مع طرق عرضها المفهرسة) طرق العرض المادية بشكلٍ أصلي، مع خيارات تحديث متنوعة (يدوية، مجدولة، وحتى تلقائية في بعض الحالات). أما في MySQL، ولعدم وجود دعم مباشر، فيتم محاكاة هذا السلوك عادةً باستخدام جداول وعمليات تُعيد إنشاء البيانات دوريًا، غالبًا من خلال المشغلات أو المهام المجدولة.
عندما يقوم استعلام بربط عدد كبير جدًا من الجداول أو يعتمد على مجموعة معقدة من طرق العرض، فإن استراتيجية أخرى صالحة هي قسّم الاستعلام إلى عدة خطواتيعني هذا تنفيذ استعلام أولي للحصول على مجموعة أصغر (مثل المعرّفات ذات الصلة)، ثم تنفيذ استعلامات إضافية لاستكمال المعلومات. ينبغي استخدام هذا الأسلوب بحذر، إذ قد يزيد من عدد عمليات الوصول إلى قاعدة البيانات، ولكنه في بعض الحالات يقلل بشكل كبير من تعقيد خطة التنفيذ وحجم المجموعات الوسيطة.
خلال هذه العملية، يتم استخدام أدوات مراقبة مثل pg_stat_statements، PgHero، PMM، Query Store، New Relic أو Datadog بإمكانهم مساعدتك في تحديد الاستعلامات الأبطأ أو التي تعمل بشكل متكرر بسرعة، حتى تتمكن من إعطاء الأولوية لجهود التحسين حيثما يكون ذلك مهمًا حقًا.
تحسين استعلامات SQL بمساعدة الذكاء الاصطناعي
وفي السنوات الأخيرة ظهرت أدوات تعتمد على الذكاء الاصطناعي تقوم هذه الأدوات بتحليل استعلاماتك ومخطط قاعدة البيانات لاقتراح تحسينات: اقتراحات الفهرسة، وإعادة كتابة الاستعلامات، وتغييرات في بنية الجدول، وما إلى ذلك. وقد أصبحت أسماء مثل EverSQL وDBScoop وPGAnalyzer وRedshift Advisor شائعة في البيئات المهنية.
تستطيع هذه الحلول مراجعة كميات كبيرة من سجلات الاستعلامات، ومقارنتها بالإحصائيات وخطط التنفيذ ومقاييس الأداء، ومن ثمّ اكتشاف الأنماط غير الفعالة أو الاختناقات قد يغيب ذلك عنا للوهلة الأولى. كما أنها تساعد في تقييم الأثر المحتمل لإنشاء أو إلغاء مؤشرات معينة.
ومع ذلك، من المهم فهمها على أنها الدعم، وليس كبديل يعتمد الأمر على معرفتك بلغة SQL وفهمك لتطبيقك. قد تتلقى اقتراحًا لفهرسة يُفترض أنه يُسرّع استعلامًا مُحددًا، ولكنه يُؤدي إلى تدهور كبير في عمليات الكتابة إلى وحدة نمطية حيوية. وبدون سياق العمل، لا تستطيع الأداة تحديد الأولويات.
إنّ المزيج الأمثل هو فريق يتقن مبادئ التحسين (الخطط، والفهارس، والتطبيع، وأنماط الوصول) ويستخدم الذكاء الاصطناعي لـ تسريع التحليل والتحقق من صحة الفرضياتعدم اتخاذ قرارات عمياء.
عندما تستوعب هذه المجموعة الكاملة من التقنيات - تصميم الفهرس بعناية، والحد الأدنى من اختيار الأعمدة، والاستخدام الذكي لعمليات الربط (JOINs) والعبارات الجدولية المشتركة (CTEs)، والترقيم الفعال للصفحات، والصيانة المنتظمة للإحصائيات، واستغلال طرق العرض المادية، وحتى الدعم من أدوات الذكاء الاصطناعي - لم تعد قواعد البيانات الضخمة وحشًا لا يمكن السيطرة عليه وتصبح هذه المكونات عنصراً قابلاً للتنبؤ والتوسع في بنية نظامك، وقادرة على النمو مع نمو أعمالك دون الإضرار بتجربة المستخدم أو ميزانية البنية التحتية.
