برومبت يقرأ خطة PostgreSQL دون تحويل التقدير إلى أداء مقاس

ظهور Seq Scan في خطة استعلام لا يكفي للحكم بأن قاعدة البيانات تحتاج فهرسًا. قد يكون مسح جدول صغير اختيارًا منطقيًا. قبل طلب «تحسين SQL»، أعطِ الأداة سؤالًا محددًا وخطة منزوعة البيانات، واطلب منها فصل الاحتمال عن القياس.

EXPLAIN والتجربة الفعلية

يوضح توثيق PostgreSQL أن EXPLAIN يعرض خطة مقدرة، بينما ANALYZE ينفذ الاستعلام للحصول على معلومات فعلية. قيم cost ليست مللي ثانية، وحجم الصفوف المتوقع ليس عدد النتائج الذي قسته بنفسك. لا تشغّل أمرًا اقترحه نموذج تلقائيًا على قاعدة الإنتاج، خصوصًا إذا كان يتضمن كتابة.

القالب القابل للنسخ

راجع خطة PostgreSQL قراءةً فقط. لا تنفذ أوامر ولا تطلب اتصالًا بقاعدة البيانات.
إصدار PostgreSQL: [اكتب]
السؤال الذي أريد الإجابة عنه: [اكتب]
مخطط الجداول والفهارس بعد إزالة أسماء وبيانات حساسة: [ألصق]
استعلام SELECT مبسط بمعاملات وهمية: [ألصق]
مخرجات EXPLAIN المنزوعة البيانات: [ألصق]
هل الخطة تحتوي ANALYZE وقياسات فعلية؟ [نعم/لا/لا أعلم]

افصل: ما يظهر في الخطة، وما تستنتجه، وما لا يمكن معرفته.
راجع شروط التصفية والربط وترتيب العمليات والصفوف المتوقعة؛ لا تعتبر أي عقدة خطأً لمجرد اسمها.
لا تحول cost إلى زمن. إن وجدت قياسات فعلية، ميّزها بوضوح عن التقديرات.
اقترح تجربة واحدة أو اثنتين في بيئة اختبار ببيانات اصطناعية مناسبة، مع المقاييس المطلوبة وحدود الاستنتاج.
لا تنشئ فهرسًا ولا تغير إعدادًا ولا تضف ANALYZE للتنفيذ دون اعتماد مستقل. اختم بالمعلومة الناقصة الأكثر تأثيرًا.

جرّب بعينة تمثل السؤال

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

ما الذي تشاركه؟

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