استعلام PostgreSQL بطيء؟ كيف تقرا EXPLAIN ANALYZE بلا ما تخرّب بياناتك

استعلام بيمرق بلحظة على جهازك، وبيوقّف الصفحة لما الجدول يكبر بالإنتاج. والأداة يلي بتقلك ليش ممكن تعدّل بياناتك إذا شغّلتها على UPDATE بلا انتباه. هون بتعرف تقرا EXPLAIN ANALYZE، وكيف تجرّبه بأمان.

شو الفرق بين EXPLAIN وEXPLAIN ANALYZE؟

الـ EXPLAIN بيورجيك الخطة يلي اختارها PostgreSQL وتخمينه لكل خطوة فيها، بلا ما ينفّذ شي. والـ EXPLAIN ANALYZE بينفّذ الاستعلام فعلاً، وبيحط جنب التخمين الأرقام الحقيقية.

الخطة بيختارها الـ planner، وهو الجزء من PostgreSQL يلي بيقرر كيف ينفّذ الاستعلام قبل ما يبلّش: يقرا الجدول كله، أو يستعمل فهرس، وبأي ترتيب يربط الجداول. قراره مبني على تخمين، والتخمين ممكن يغلط.

حسب صفحة استعمال EXPLAIN بتوثيق PostgreSQL، الناتج فيه سطر لكل عقدة (node) بالخطة: نوعها، وتخمين الـ planner إلها. ومع ANALYZE بيزيد على كل عقدة عدد الصفوف الحقيقي والوقت الحقيقي يلي أخدته.

شو بتعني الأرقام بين القوسين؟

الأرقام بين القوسين هي تخمين الـ planner للعقدة: كلفة البداية، والكلفة الكاملة، وعدد الصفوف، وعرض الصف. هاد مثال التوثيق نفسه:

EXPLAIN SELECT * FROM tenk1;

 Seq Scan on tenk1  (cost=0.00..445.00 rows=10000 width=244)

الـ cost مش بالثواني: هو بوحدات اعتباطية بيحددها الـ planner. بالمثال ما في WHERE، فالـ planner اختار Seq Scan، يعني قراية كل صفوف الجدول.

ليش EXPLAIN ANALYZE خطير على UPDATE وDELETE؟

الـ EXPLAIN ANALYZE بينفّذ الاستعلام عن جد، فأي تعديل فيه بيصير. الـ EXPLAIN بيرمي الصفوف يلي بيرجّعها SELECT، بس UPDATE بيعدّل، وDELETE بيحذف، متل لو شغّلتهن لحالهن.

هون الغلطة يلي بتصير: حدا بدّه يعرف ليش DELETE بطيء، بيكتب قبله EXPLAIN ANALYZE على قاعدة الإنتاج، وبيطلع معه التقرير والصفوف محذوفة.

صفحة أمر EXPLAIN بالتوثيق بتعطي الحل: لفّه بـ transaction وارجع عنه. هيك بتنطبّق على INSERT وUPDATE وDELETE وMERGE كمان:

BEGIN;
EXPLAIN ANALYZE UPDATE tenk1 SET hundred = hundred + 1 WHERE unique1 < 100;
ROLLBACK;

بتشوف الخطة والأرقام الحقيقية، وROLLBACK بيرجّع الجدول متل ما كان.

كيف تقرا actual time وloops؟

الـ actual time هو الوقت الحقيقي بالعقدة بالميلي ثانية، والـ loops هو عدد المرات يلي انفذت فيها العقدة. لما العقدة بتنفّذ أكتر من مرة، الوقت وعدد الصفوف يلي بتشوفهن معدّل للمرة الوحدة.

يعني عقدة جوّا حلقة ممكن تبيّن سريعة، وهي أخدت أغلب وقت الاستعلام. اضرب actual time بـ loops لتعرف الوقت الكامل يلي أخدته.

وما تقارن الـ cost بالـ actual time: واحد بوحدات اعتباطية والتاني بالميلي ثانية. المقارنة المفيدة بين rows المتوقع وrows الحقيقي بنفس العقدة. لما الفرق كبير، الـ planner اختار خطته على رقم غلط، وهون غالباً بتلاقي سبب البطء.

شو بيعطيك BUFFERS؟

الـ BUFFERS بيورجيك شغل القراية والكتابة بكل عقدة: عدد الـ blocks يلي انلقت (hit)، ويلي انقرت (read)، ويلي اتّسخت (dirtied)، ويلي انكتبت (written). بالتوثيق الحالي، ANALYZE بيضيفه لحاله.

هالأرقام بتفيدك لما الوقت بيختلف بين جهازك والإنتاج والخطة نفسها: بتورجيك إذا العقدة عم تشتغل على عدد blocks مختلف. وإذا ما شفت سطور Buffers بالناتج عندك، اكتبه بنفسك: EXPLAIN (ANALYZE, BUFFERS).

من وين تبلّش هلق؟

بلّش بالاستعلام البطيء نفسه، على نسخة من البيانات قريبة من الإنتاج.

1. شغّل EXPLAIN ANALYZE قبله، وإذا هو INSERT أو UPDATE أو DELETE، لفّه بـ BEGIN وROLLBACK.

2. دوّر على العقدة يلي فيها أكبر فرق بين rows المتوقع والحقيقي.

3. اضرب وقتها بـ loops، وشوف إذا هي فعلاً يلي أخدت الوقت.

4. إذا هي Seq Scan على جدول كبير وعليها شرط WHERE، جرّب فهرس على عمود الشرط، وأعد نفس القراية.

وإذا عم تبني أساسك بالبرمجة وقواعد البيانات، خارطة طريق المبرمج 2026 بترتّبلك شو تتعلم بعدين.

ومقالات أدوات المطوّرين كلها بمكان واحد: أدوات المطورين.

وإذا الاستعلام البطيء ورا صفحة بموقعك، بتلاقي مقالات الشغل على المواقع نفسها بـ تطوير الويب.