Skip to main content
يعرض خطة تنفيذ عبارة.
الصيغة:
مثال:

أنواع EXPLAIN

  • AST — شجرة البنية النحوية المجردة.
  • SYNTAX — نص الاستعلام بعد التحسينات على مستوى AST.
  • QUERY TREE — شجرة الاستعلام بعد التحسينات على مستوى Query Tree.
  • PLAN — خطة تنفيذ الاستعلام.
  • PIPELINE — مسار تنفيذ الاستعلام.

EXPLAIN AST

يعرض AST للاستعلام. يدعم جميع أنواع الاستعلامات، وليس SELECT فقط. الإعدادات:
  • graph – يطبع AST على شكل رسم بياني موصوف بلغة وصف الرسوم البيانية DOT. القيمة الافتراضية: 0.
أمثلة:

EXPLAIN SYNTAX

يعرض شجرة البنية النحوية المجرّدة (AST) للاستعلام بعد تحليل البنية النحوية. يتم ذلك عبر تحليل الاستعلام، وبناء AST وشجرة الاستعلام، وتشغيل محلل الاستعلامات وتمريرات التحسين اختياريًا، ثم تحويل شجرة الاستعلام مرة أخرى إلى AST الخاصة بالاستعلام. الإعدادات:
  • oneline – يطبع الاستعلام في سطر واحد. القيمة الافتراضية: 0.
  • run_query_tree_passes – يشغّل تمريرات شجرة الاستعلام قبل إخراج شجرة الاستعلام. القيمة الافتراضية: 0.
  • query_tree_passes – إذا كان run_query_tree_passes مضبوطًا، فإنه يحدّد عدد التمريرات التي سيتم تشغيلها. ومن دون تحديد query_tree_passes، يتم تشغيل جميع التمريرات.
أمثلة:
Query
Response
باستخدام run_query_tree_passes:
Query
Response

EXPLAIN شجرة الاستعلام

الإعدادات:
  • run_passes — شغّل جميع تمريرات شجرة الاستعلام قبل إخراج شجرة الاستعلام. القيمة الافتراضية: 1.
  • dump_passes — أخرج معلومات عن التمريرات المستخدمة قبل إخراج شجرة الاستعلام. القيمة الافتراضية: 0.
  • passes — يحدّد عدد التمريرات المطلوب تشغيلها. إذا ضُبطت على -1، فسيُشغّل جميع التمريرات. القيمة الافتراضية: -1.
  • dump_tree — اعرض شجرة الاستعلام. القيمة الافتراضية: 1.
  • dump_ast — اعرض AST للاستعلام الناتجة من شجرة الاستعلام. القيمة الافتراضية: 0.
مثال:

EXPLAIN PLAN

يعرض خطوات خطة تنفيذ الاستعلام. الإعدادات:
  • optimize — يتحكم في ما إذا كانت تحسينات خطة تنفيذ الاستعلام تُطبَّق قبل عرض الخطة. القيمة الافتراضية: 1.
  • header — يطبع ترويسة المخرجات للخطوة. القيمة الافتراضية: 0.
  • description — يطبع وصف الخطوة. القيمة الافتراضية: 1.
  • indexes — يعرض الفهارس المستخدمة، وعدد الأجزاء التي تمت تصفيتها، وعدد الحبيبات التي تمت تصفيتها لكل فهرس مُطبَّق. القيمة الافتراضية: 0. مدعوم في جداول MergeTree. بدءًا من ClickHouse >= v25.9، لا تعرض هذه العبارة ناتجًا مناسبًا إلا عند استخدامها مع SETTINGS use_query_condition_cache = 0, use_skip_indexes_on_data_read = 0.
  • projections — يعرض جميع الإسقاطات التي جرى تحليلها وتأثيرها في التصفية على مستوى الأجزاء استنادًا إلى شروط المفتاح الأساسي للإسقاط. ولكل إسقاط، يتضمن هذا القسم إحصاءات مثل عدد الأجزاء والصفوف وعلامات ونطاقات التي جرى تقييمها باستخدام المفتاح الأساسي للإسقاط. كما يوضح عدد data parts التي تم تخطيها بسبب هذه التصفية، من دون القراءة من الإسقاط نفسه. ويمكن تحديد ما إذا كان الإسقاط قد استُخدم فعليًا للقراءة أو جرى تحليله فقط لأغراض التصفية من خلال الحقل description. القيمة الافتراضية: 0. مدعوم في جداول MergeTree.
  • actions — يطبع معلومات تفصيلية عن إجراءات الخطوة. القيمة الافتراضية: 1.
  • sorting — يطبع وصف الفرز لكل خطوة في الخطة تنتج مخرجات مرتبة. القيمة الافتراضية: 0.
  • keep_logical_steps — يحتفظ بالخطوات المنطقية في الخطة لعمليات joins بدلًا من تحويلها إلى تطبيقات join فعلية. القيمة الافتراضية: 0.
  • json — يطبع خطوات خطة تنفيذ الاستعلام كسطر بتنسيق JSON. القيمة الافتراضية: 0. يُنصح باستخدام تنسيق TabSeparatedRaw (TSVRaw) لتجنب عمليات إفلات غير الضرورية.
  • input_headers — يطبع ترويسات الإدخال للخطوة. القيمة الافتراضية: 0. يفيد غالبًا المطورين فقط في استكشاف المشكلات المتعلقة بعدم تطابق ترويسات الإدخال والإخراج.
  • column_structure — يطبع أيضًا بنية الأعمدة في الترويسات بالإضافة إلى اسمها ونوعها. القيمة الافتراضية: 0. يفيد غالبًا المطورين فقط في استكشاف المشكلات المتعلقة بعدم تطابق ترويسات الإدخال والإخراج.
  • distributed — يعرض خطط الاستعلام المنفَّذة على العقد البعيدة للجداول الموزعة أو parallel replicas. غير مدعوم مع json. القيمة الافتراضية: 0.
  • compact — عند التمكين، يُخفي خطوات expression ومعلومات الإجراءات التفصيلية (المدخلات، والدوال، والأسماء المستعارة، ومواضع المخرجات) من الخطة. ولا يكون له تأثير إلا عندما تكون actions = 1. القيمة الافتراضية: 1.
  • pretty — يطبع شجرة الخطة باستخدام محارف رسم الخطوط (├──, └──, │) بدلًا من المسافات البادئة لتوضيح التدرج الهرمي. كما ينسّق خصائص خطوة join ضمن السطر نفسه. القيمة الافتراضية: 1.
افتراضيًا، تكون قيمة explain_query_plan_default = 'pretty'، لذلك تُهيَّأ actions وcompact وpretty إلى 1، وتُعرَض الخطة بصيغة مضغوطة وجميلة ومشروحة بالإجراءات. ويؤدي تحديد أي من هذه الخيارات صراحةً في عبارة EXPLAIN (على سبيل المثال، EXPLAIN actions = 0, compact = 0, pretty = 0 SELECT ...) دائمًا إلى تجاوز القيمة الافتراضية.قبل ClickHouse 26.7، كانت القيم الافتراضية لكل من actions وcompact وpretty هي 0. ولا يزال بإمكانك الحصول على ذلك الناتج من خلال ضبط explain_query_plan_default = 'legacy' (على مستوى عام أو ضمن SETTINGS الخاصة بكل استعلام)، أو عن طريق ضبط compatibility على أي إصدار أقدم من 26.7.لا يؤدي الخياران json وdistributed إلى تفعيل إعدادات pretty الافتراضية (actions وcompact وpretty)، حتى عندما تكون قيمة explain_query_plan_default = 'pretty'. ولتضمين تفاصيل الإجراءات في مخرجاتهما، اضبط actions = 1 يدويًا.
مثال:
لا تتوفر إمكانية تقدير تكلفة الخطوة والاستعلام.
عند ضبط json = 1، تُمثَّل خطة تنفيذ الاستعلام بصيغة JSON. كل عقدة هي قاموس يحتوي دائمًا على المفاتيح Node Type وNode Id وPlans. تكون Node Type سلسلة نصية تتضمن اسم الخطوة، ويكون Node Id معرّفًا فريدًا للخطوة (اسم الخطوة مع لاحقة رقمية، مثل Union_10). أما Plans فهي مصفوفة من أوصاف الخطوات الفرعية. وقد تُضاف مفاتيح اختيارية أخرى بحسب نوع العقدة والإعدادات. مثال:
عند ضبط description = 1، يُضاف المفتاح Description إلى الخطوة:
عند ضبط header = 1، يُضاف المفتاح Header إلى الخطوة على هيئة مصفوفة من الأعمدة. مثال:
مع indexes = 1، يُضاف المفتاح Indexes. ويحتوي على مصفوفة من الفهارس المستخدمة. يُوصَف كل فهرس بتنسيق JSON مع المفتاح Type (سلسلة نصية بقيمة Partition Min-Max أو Partition أو Statistics أو PrimaryKey أو Skip) والمفاتيح الاختيارية التالية:
  • Name — اسم الفهرس (يُستخدم حاليًا فقط مع فهارس Skip).
  • Keys — مصفوفة الأعمدة التي يستخدمها الفهرس.
  • Condition — الشرط المستخدم.
  • Description — وصف الفهرس (يُستخدم حاليًا فقط مع فهارس Skip).
  • Parts — عدد الأجزاء بعد/قبل تطبيق الفهرس.
  • Granules — عدد الحبيبات بعد/قبل تطبيق الفهرس.
  • Ranges — عدد نطاقات الحبيبات بعد تطبيق الفهرس.
مثال:
عند تعيين projections = 1، يُضاف مفتاح Projections، ويحتوي على مصفوفة من الإسقاطات المُحللة. يُوصف كل إسقاط بصيغة JSON وفق المفاتيح التالية:
  • Name — اسم الإسقاط.
  • Condition — شرط المفتاح الأساسي المستخدم في الإسقاط.
  • Description — وصف كيفية استخدام الإسقاط (على سبيل المثال، التصفية على مستوى الجزء).
  • Selected Parts — عدد الأجزاء التي اختارها الإسقاط.
  • Selected Marks — عدد العلامات المختارة.
  • Selected Ranges — عدد النطاقات المختارة.
  • Selected Rows — عدد الصفوف المختارة.
  • Filtered Parts — عدد الأجزاء التي جرى تخطيها بسبب التصفية على مستوى الجزء.
مثال:
مع actions = 1، تعتمد المفاتيح المضافة على نوع الخطوة. مثال:
مع compact = 0 وactions = 1، يمكن رؤية خطوات Expression مع معلومات مفصلة عن التعبيرات:
عند تعيين distributed = 1، يتضمن الناتج ليس فقط خطة الاستعلام المحلية، بل أيضاً خطط الاستعلام التي ستُنفَّذ على العقد البعيدة. يُفيد هذا في تحليل الاستعلامات الموزعة وتصحيح أخطائها.
لا يُعرَض distributed إلا بصيغة legacy (غير pretty)، لأن مخرجات pretty لا تدمج خطط المقاطع البعيدة في شجرة الخطة. ولهذا السبب، يؤدي تمكين distributed تلقائيًا إلى تعطيل الإعدادات الافتراضية لـpretty (actions وcompact وpretty)، بغضّ النظر عن explain_query_plan_default. ولا يزال بإمكانك تعيين actions=1 يدويًا. كما أن الخيار distributed غير مدعوم أيضًا مع json.
مثال مع جدول موزّع:
مثال مع النسخ المتماثلة المتوازية:
في كلا المثالَين، تُظهر خطةُ الاستعلام تدفق التنفيذ الكامل بما في ذلك الخطوات المحلية والبعيدة. عند تعيين pretty = 1، تُعرض شجرة الخطة باستخدام أحرف رسم الخطوط بدلاً من المسافات البادئة، وتظهر معلومات إضافية للخطوات الرئيسية:
  • تُطبَع أعمدة ناتج الاستعلام في أعلى الخطة.
  • تُعرَض التعبيرات في عوامل التصفية، ومفاتيح التجميع، وأوصاف الفرز، ودوال النوافذ بصياغة مقروءة للبشر شبيهة بـ SQL (مثلًا، a + 1 > 5 بدلًا من greater(plus(a, 1), 5)). وتُزال بادئات معرّفات الأعمدة الداخلية (مثل __table1.) لتوضيح العرض.
  • تعرض خطوات المصدر (مثل ReadFromMergeTree) أعمدة ناتجها.
  • تعرض خطوات التصفية شرط التصفية بصياغة SQL. وعند وجود عوامل تصفية للربط وقت التشغيل، تُعرض بشكل منفصل.
  • تعرض خطوات التجميع المفاتيح والدوال التجميعية مع وسيطاتها (مثل sum(c) وcount()).
  • تُظهر مجموعات IN من قيم tuple الحرفية قيمها (مقتطعةً للمجموعات الكبيرة)، وتُوسَم المجموعات المستندة إلى استعلامات فرعية على أنها subquery1 وsubquery2 وما إلى ذلك، وتُظهر المجموعات من جداول محرك Set اسم الجدول.
  • تعرض خطوات الربط علاقة الربط باستخدام ترميز رياضي، والعدد التقديري لصفوف النتيجة، وأي أعمدة ناتج تأتي من الجانب الأيسر مقابل الجانب الأيمن. وتُستخدم الرموز التالية لتمثيل أنواع الربط المختلفة:
على سبيل المثال، t1 ⟕ t2 تعني LEFT JOIN بين الجدولين t1 وt2. ويشير الرقم بين القوسين بعد اسم الجدول (مثل t1[100]) إلى العدد التقديري للصفوف عندما تكون إحصاءات الجدول متاحة. يعمل الخيار pretty جيدًا مع compact = 1، إذ يُخفي خطوات Expression ومعلومات الإجراءات التفصيلية، مما يجعل الخطة أسهل في القراءة. مثال تفصيلي يتضمن عمليات JOIN:

EXPLAIN PIPELINE

الإعدادات:
  • header — يطبع الترويسة لكل منفذ إخراج. القيمة الافتراضية: 0.
  • graph — يطبع رسمًا بيانيًا موصوفًا بلغة وصف الرسوم البيانية DOT. القيمة الافتراضية: 0.
  • compact — يطبع الرسم البياني في الوضع المضغوط إذا كان إعداد graph مفعّلًا. القيمة الافتراضية: 1.
  • compact_repeated_processor_chains — يضغط سلاسل المعالجات المتكررة والمتجاورة في المخرجات النصية، وذلك بعرض نسخة واحدة من السلسلة مع عدد مرات تكرارها. يمكن أن يجعل ذلك خطوط المعالجة المتوازية أسهل قراءةً عندما تتكرر السلسلة نفسها مرات عديدة، على سبيل المثال في عمليات JOIN. ولا يؤثر ذلك في مخرجات الرسم البياني. القيمة الافتراضية: 0.
عندما تكون compact=0 وgraph=1، ستتضمن أسماء المعالجات لاحقة إضافية تحتوي على معرّف فريد للمعالج. مثال:

EXPLAIN ESTIMATE

يعرض العدد التقديري للصفوف والعلامات والأجزاء التي ستُقرأ من الجداول عند معالجة الاستعلام. يعمل مع الجداول من عائلة MergeTree. مثال إنشاء جدول:
Query
Query
Response

EXPLAIN WHATIF

يقدّر الفائدة التي يمكن أن يوفّرها فهرس تخطٍّ افتراضي لاستعلام SELECT، من دون إجراء materializing للفهرس على القرص. حدِّد مرشحًا واحدًا أو أكثر باستخدام CREATE HYPOTHETICAL INDEX، ثم شغّل EXPLAIN WHATIF SELECT ... لمعرفة ما يلي لكل مرشح: مدى قابليته للتطبيق، والعدد التقديري للعلامات المقروءة، والبايتات التقديرية، ونسبة التخطي. الصياغة
الإعدادات
  • empirical — تؤدي القيمة 1 (الافتراضية) إلى تشغيل الفهرس في الذاكرة على الحبيبات التي جرى تقليصها وفق خط الأساس، وذلك لقياس نسبة التخطي (وهي حدٌّ أعلى). أما 0 فتتخطى هذا المسار. وفي كلتا الحالتين، إذا لم يُنتج empirical نتيجة (إما لأنه معطَّل أو لأن الفهرس لا يمكن تقييمه في الذاكرة)، فإن المُقدِّر يعود إلى إحصاءات الأعمدة، ثم أخيرًا إلى ملخص يقتصر على قابلية التطبيق فقط إذا لم يتوفر أيٌّ منهما.
المخرجات
  • source — كيفية احتساب التقدير.
    • empirical: جرى بناء الفهرس في الذاكرة على الحبيبات المتبقية بعد استبعاد خط الأساس، ثم عُدَّت الحبيبات التي سيتجاوزها الفهرس. وهذا يمثل حدًا أعلى — راجع القيود في CREATE HYPOTHETICAL INDEX.
    • statistical: مشتق من إحصاءات الأعمدة. يُستخدم عندما يكون empirical معطّلًا (empirical = 0) أو عندما يتعذر على empirical إنتاج نتيجة، مع توفّر إحصاءات أعمدة للأعمدة ذات الصلة.
    • applicability_only: الفهرس قابل للتطبيق على الشرط، لكن لم يُنتج لا التقدير التجريبي ولا الإحصائي نتيجة (مثلًا، empirical = 0 مع عدم تعريف إحصاءات أعمدة). ويعرض skip_ratio: 0.0% بوصفه حدًا محافظًا.
  • sampled_parts / sampled_marks<baseline-pruned> / <total in the table>. يوضح ذلك أي نسبة من الجدول بقيت بعد استبعاد PK والتقسيم والفهارس الموجودة، أي ما يُستخدم كمدخل إلى الفهرس الافتراضي.
  • est_bytes — تقدير لعدد البايتات المقروءة، مشتق من متوسط حجم الصف في الجدول، لذا فهو تقريبي ويتفاوت حسب التخزين والضغط. لا يظهر سطر خط الأساس إلا عندما يقرأ الاستعلام صفوفًا؛ ولا يظهر السطر الخاص بكل مرشح إلا عندما يكون تقدير بايتات خط الأساس معروفًا.
يُكتب الإعداد Inline بين WHATIF وSELECT — ولا توجد الكلمة المفتاحية SETTINGS (وهذا يطابق الطريقة التي تقبل بها متغيرات EXPLAIN الأخرى خياراتها). إذا لم تكن هناك فهارس افتراضية معرّفة للجدول، فسيعرض EXPLAIN WHATIF القيمة status: not_applicable مع تلميح لإنشاء فهرس. مثال تجريبي
سيؤدي minmax الافتراضي إلى تقليص عدد العلامات من 100 إلى علامة واحدة — skip_ratio: 99.0%. (القيمة est_bytes هي تقدير مستند إلى متوسط حجم الصف، لذا قد يختلف الرقم الفعلي.) مثال إحصائي تكون الإحصاءات الخاصة بالأعمدة غير مفعّلة افتراضيًا. لاستخدام المسار statistical، عرّفها أولًا على الأعمدة ذات الصلة ثم انتظر حتى تكتمل عملية mutation الخاصة بـ materialize:
ثم عطِّل المسار التجريبي ليعتمد المُقدِّر على إحصاءات الأعمدة:
يأتي الرقم من انتقائية إحصاءات العمود للتعبير b < 10 (نحو 10 صفوف من أصل 10000)، ويُورَد باعتباره حدًا أعلى لـ skip_ratio. ولا توجد sampled_parts / sampled_marks — إذ لم تُقرأ أي بيانات. إذا لم يكن أيٌّ من المسارين متاحًا (مثلًا، empirical = 0 ولم تُعرَّف أي إحصاءات أعمدة)، فإن المُقدِّر يُرجع source: applicability_only وskip_ratio: 0.0% بشكل متحفّظ.

EXPLAIN TABLE OVERRIDE

يعرض ناتج تطبيق تجاوز على مخطط جدول تم الوصول إليه عبر دالة جدول. كما يُجري بعض عمليات التحقق، ويُطلق استثناءً إذا كان هذا التجاوز سيتسبب في أي نوع من الإخفاق. مثال افترض أن لديك جدول MySQL بعيدًا على النحو التالي:
Query
Query
Response
لم تكتمل عملية التحقق، لذا فإن نجاح الاستعلام لا يضمن أن الاستبدال لن يسبب مشكلات.
آخر تعديل في ١ يوليو ٢٠٢٦