عندما يكون الاستعلام بطيئًا، فإن أسوأ رد فعل هو تحسينه بحسب الحدس.
تخبرك PostgreSQL بالفعل بكيفية تنفيذ الاستعلام. تحتاج فقط إلى أن تسأل.
هذا هو الغرض من EXPLAIN ANALYZE.
ابدأ بالخطة، وليس النظرية
EXPLAIN ANALYZE
SELECT *
FROM users
WHERE status = 'archived';
هذا يعطيك خطة التنفيذ الفعلية، وليس فقط نص SQL الذي كنت تأمل أن يكون فعالًا.
الأشياء الأولى التي يجب النظر إليها
لا تحتاج إلى إتقان كل عقدة في الخطة في اليوم الأول. ابدأ بـ:
- نوع المسح: المسح التسلسلي مقابل الوصول المدعوم بالفهرس
- الصفوف المقدرة مقابل الصفوف الفعلية
- إجمالي وقت التنفيذ
- ما إذا كانت الخطوات المكلفة تتكرر عدة مرات
غالبًا ما تكون هذه كافية لتفسير معظم الحوادث "لماذا هو بطيء؟".
المسح التسلسلي ليس سيئًا تلقائيًا
إحدى الأخطاء الشائعة بين المبتدئين هي الافتراض بأن كل Seq Scan هو خطأ.
ليس كذلك.
إذا كانت الجدول صغيرًا أو كان الاستعلام يحتاج إلى نسبة كبيرة من الصفوف على أي حال، فالمسح التسلسلي يمكن أن يكون الخطة الصحيحة.
السؤال الحقيقي هو ما إذا كانت الخطة المختارة تتناسب مع عبء العمل.
ما الذي يغيره الفهرس بشكل عام
إذا كان الفلتر الانتقائي يفتقر إلى فهرس مفيد، فقد لا يكون لدى PostgreSQL طريقة رخيصة لتضييق نطاق البحث.
يمكن أن يغير إضافة فهرس ذلك:
CREATE INDEX idx_users_status ON users(status);
ولكن حتى بعد ذلك، لا تتوقف عند "تمت إضافة الفهرس". أعد تشغيل EXPLAIN ANALYZE وتأكد من أن الخطة الجديدة أفضل بالفعل.
المهارة الحقيقية
قراءة خطط التنفيذ أقل عن حفظ أسماء العقد وأكثر عن السؤال:
- كم عدد الصفوف التي اعتقدت PostgreSQL أنها ستلمس؟
- كم عدد الصفوف التي لمستها فعليًا؟
- أين يتم قضاء الوقت؟
- هل الخطة تؤدي أعمالًا متكررة؟
هذا هو الطريق من الفلكلور إلى الهندسة.
قراءة إضافية