يرسل فريق الدعم استعلام تقرير بطيء ويطلب «تحليل الخطة». يضيف أحدهم ANALYZE ظنًا أنه يقرأ معلومات فقط. في PostgreSQL، هذا الاختيار يغير طبيعة الفحص لأنه ينفذ الاستعلام فعلًا. ابدأ بتحديد الأمر والبيئة والأثر المتوقع قبل تشغيل أي أداة على قاعدة الإنتاج.
ميز التقدير من القياس الفعلي
توضح وثائق PostgreSQL 17 لشرح الخطط أن EXPLAIN يعرض الخطة المقدرة، بينما ينفذ EXPLAIN ANALYZE الاستعلام ويضيف أعداد صفوف وأزمنة فعلية للعقد. وتنبّه إلى حدوث الآثار الجانبية المعتادة. لذلك لا تعامل كلمة «تحليل» بوصفها ضمانًا لعملية قراءة بلا أثر.
حتى استعلام يبدو للوهلة الأولى قراءة قد يستدعي دالة ذات أثر جانبي. راجع النص والدوال والصلاحيات قبل التنفيذ. تستخدم هذه المقالة سيناريو تجربة مقترحًا، ولا تطلب تشغيل أمر غير مراجع على بيانات العملاء أو نشر خطة تحتوي على أسماء أو قيم حساسة.
جهز تجربة معزولة قابلة للفهم
- حدد الاستعلام ومعاملاته وغرض التقرير الذي يمثله.
- استعمل بيئة اختبار معزولة وبيانات مصطنعة أو منقحة وفق السياسة.
- راجع نسخة PostgreSQL والفهارس والإحصاءات وحجم العينة.
- ابدأ بالخطة المقدرة ثم اعتمد التنفيذ المقاس عندما تكون آثاره مفهومة ومسموحة.
لا تفترض أن ROLLBACK يصلح كل أثر خارجي، مثل استدعاء خدمة من دالة؛ العزل ومراجعة الآثار يسبقان الاعتماد على التراجع. وحدد حدًا مناسبًا للوقت والموارد حتى لا تتحول تجربة التشخيص إلى حمل غير مضبوط في بيئة مشتركة.
قارن الصفوف والسياق قبل الأرقام
في مثال افتراضي، يقدر المخطط عددًا صغيرًا من الصفوف ثم يعالج فعليًا عددًا أكبر بكثير. سجل موضع الفرق وحجم البيانات ومعاملات الطلب قبل اقتراح فهرس. لا تعتبر وحدة cost مللي ثانية، ولا تجمع أزمنة العقد المتداخلة دون فهم طريقة عرض الخطة.
سلّم استنتاجًا محدودًا بالدليل
احتفظ بالخطة قبل التغيير وبعده ونسخة الاستعلام وسياق القياس، وافحص صحة الناتج أيضًا. ضمن تقارير ERP والفحص التقني فرق بين نتيجة عينة الاختبار وأداء الإنتاج. معيار القبول تشخيص قابل للتكرار يفسر البطء ويعرف حدود القياس، مع عدم تحويل أداة التحليل إلى تنفيذ غير مقصود.
