ستساعدنا خيارات التصور المختلفة في هذا :
عرض نص مخفض
يتسبب النص الأصلي لخطة بسيطة نوعًا ما في حدوث مشكلات عند التحليل:
لذلك ، فإننا نفضل النموذج المختصر ، عندما يتم إخراج المعلومات الأساسية حول وقت التنفيذ والمخازن المؤقتة المستخدمة لكل عقدة إلى اليسار واليمين ، ومن السهل جدًا ملاحظة الحد الأقصى:
مخطط دائري
لكن في بعض الأحيان يكون من الصعب فهم "أين هو أكثر ضررًا" ، خاصة إذا كان يحتوي على عدة عشرات من العقد وحتى الشكل المختصر للخطة يستغرق 2-3 شاشات.
في هذه الحالة ، سينقذ المخطط الدائري المعتاد: على
الفور ، مرتجلاً ، يمكنك رؤية الحصة التقريبية لاستهلاك الموارد بواسطة كل عقد. عندما نمر فوقه ، على اليسار في عرض النص ، سنرى رمزًا للعقدة المحددة.
البلاط
للأسف ، لا يُظهر البرنامج العلاقة بين العقد المختلفة والنقاط "الأكثر سخونة". لهذا ، يعد خيار "البلاط" أكثر ملاءمة:
مخطط التنفيذ
لكن كلا الخيارين لا يُظهران السلسلة الكاملة لمرفقات عقد الخدمة
CTE/InitPlain/SubPlan- يمكن رؤيتها فقط في مخطط التنفيذ الحقيقي:
مطلوب المزيد من المقاييس!
إذا قمت بتصوير خطة التنفيذ الفعلي للاستعلام
EXPLAIN (ANALYZE)، فسترى فقط الوقت المنقضي هناك . لكن في كثير من الأحيان لا يكفي هذا لاستنتاجات صحيحة!
على سبيل المثال ، من خلال تنفيذ استعلام على ذاكرة تخزين مؤقت "باردة" ، ستتلقى (لكنك لن ترى!) وقت استلام البيانات من الوسائط ، وليس على الإطلاق عمل الاستعلام نفسه.
لذلك ، هناك بعض التوصيات:
- تُستخدم لمعرفة حجم صفحات البيانات التي يتم طرحها. لا تخضع هذه القيمة عمليًا للتقلبات من حمل الخادم نفسه ويمكن استخدامها كمقياس للتحسين.
EXPLAIN (ANALYZE, BUFFERS) - تُستخدم
track_io_timingلفهم المدة التي استغرقها العمل مع شركة الاتصالات بالضبط .
وإذا كانت خطتك لا تحتوي فقط على الوقت ، ولكن أيضًا ،
buffersأو i/o timingsفي كل من خيارات الرسم التخطيطي ، يمكنك التبديل إلى وضع التحليل لهذه المقاييس. في بعض الأحيان يمكنك أن ترى على الفور ، على سبيل المثال ، أن أكثر من نصف جميع القراءات وقعت في عقدة مشكلة واحدة:
المقالات السابقة حول الموضوع: