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

أنواع EXPLAIN

  • AST — شجرة البنية النحوية المجردة.
  • SYNTAX — نص الاستعلام بعد التحسينات على مستوى AST.
  • QUERY TREE — شجرة الاستعلام بعد التحسينات على مستوى شجرة الاستعلام.
  • PLAN — خطة تنفيذ الاستعلام.
  • PIPELINE — مسار تنفيذ الاستعلام.
  • ANALYZE — ينفّذ الاستعلام ويُرفق بخطة التنفيذ مقاييس وقت التشغيل المقاسة.
  • ESTIMATE — العدد التقديري للصفوف والعلامات والأجزاء التي ستُقرأ من الجداول أثناء معالجة الاستعلام.
  • TABLE OVERRIDE — النتيجة التي تم التحقق من صحتها لتجاوز جدول على مخطط دالة الجدول.

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 ANALYZE

يقوم EXPLAIN ANALYZE فعليًا بتشغيل الاستعلام، ثم يتجاهل صفوف النتائج ويطبع شجرة الخطة نفسها كما في EXPLAIN PLAN، مع إرفاق كل خطوة بتفاصيل عمّا حدث فعليًا أثناء التنفيذ. الإعدادات: يقبل EXPLAIN ANALYZE خيارات العرض نفسها التي يقبلها EXPLAIN PLAN (وهي موثقة في قسم EXPLAIN PLAN).
  • header — راجع قسم EXPLAIN PLAN.
  • description — راجع قسم EXPLAIN PLAN.
  • projections — راجع قسم EXPLAIN PLAN.
  • sorting — راجع قسم EXPLAIN PLAN.
  • input_headers — راجع قسم EXPLAIN PLAN.
  • column_structure — راجع قسم EXPLAIN PLAN.
  • actions — راجع قسم EXPLAIN PLAN. القيمة الافتراضية: 1.
  • indexes — راجع قسم EXPLAIN PLAN. القيمة الافتراضية: 1.
  • compact — راجع قسم EXPLAIN PLAN. القيمة الافتراضية: 1.
  • pretty — راجع قسم EXPLAIN PLAN. القيمة الافتراضية: 1.
  • processors — في EXPLAIN ANALYZE، يطبع سطرًا إضافيًا لكل مرحلة يتضمن توزيع الزمن المنقضي لكل معالج: min وmedian وmax وsum. ويفيد ذلك في اكتشاف اختلال توزيع الحمل بين المعالجات المتوازية. القيمة الافتراضية: 0.
لأن EXPLAIN ANALYZE ينفّذ الاستعلام المغلّف فعليًا، فهو يتصرف مثل ذلك الاستعلام — وعلى خلاف صيغ EXPLAIN التي لا تنفّذ شيئًا — بعدة طرق:
  • الحصص والحدود. يُحتسب ضمن الحصص ويخضع لنفس الحدود (مثل query_selects وread_rows) كما لو كنت تشغّل الاستعلام مباشرةً. ولا تُحتسب المصادر المعفاة من الحصص أثناء التخطيط (مثل system.one).
  • المعاملات الفاشلة. داخل معاملة سبق أن فشلت (ROLLED_BACK)، يُرفَض مع INVALID_TRANSACTION, تمامًا مثل SELECT عادي — أصدر ROLLBACK أولًا.
  • القراءات المتدفقة. عند إجراء قراءة متدفقة (FROM ... STREAM) يُرفَض مع NOT_IMPLEMENTED، لأن هذا النوع من القراءة لا يكتمل أبدًا.
  • الاستعلامات الموزعة. هذا غير مدعوم للاستعلامات التي تُنفَّذ في وضع Distributed.
مثال:
لنفحص الناتج. أولاً، لننظر إلى الترويسة.
  • Time — الوقت الإجمالي، مقسَّماً إلى مرحلتَي التخطيط (أي إنشاء الخطة + تحسين الخطة + بناء pipeline) والتنفيذ (تشغيل pipeline).
  • Read — الصفوف والبايتات غير المضغوطة المقروءة من الجداول، مع معدل النقل — وهي الأرقام نفسها التي يَعرضها تذييل الاستعلام العادي تحت اسم “Processed”.
  • Peak memory — ذروة الذاكرة التي استخدمها الاستعلام.
والآن لنلقِ نظرة على الأسطر الجديدة التي تظهر في خطة الاستعلام.
يُبلَّغ عن الصفوف والبايتات مرة واحدة للخطوة بأكملها (سطر I/O). ويُبلَّغ عن الوقت ودرجة التوازي لكل مرحلة من مراحل الخطوة في السطر أو الأسطر التالية ذات المسافة البادئة.
  • rows <in> → <out> — الصفوف التي دخلت الخطوة وخرجت منها؛ وتُظهر (<selectivity>%) مقدار ما قامت الخطوة بتصفيته (out/in) أو توسيعه للبيانات. ويُخفى هذا عندما يتساوى عدد صفوف الإدخال مع عدد صفوف الإخراج، وعندما يساوي عدد صفوف الإدخال 0.
  • <bytes_in> → <bytes_out> — بايتات غير مضغوطة داخل الذاكرة تمر عبر الخطوة (يُحذف هذا إذا كانت القيمتان صفراً).
  • time <t> (<share>%) — زمن الساعة الفعلي الذي كانت المرحلة نشطة خلاله، ونسبتها من وقت تنفيذ الاستعلام (أي من دون وقت البناء). لاحظ أن مجموع النسب قد يتجاوز 100% لأن المراحل والخطوات تعمل بالتوازي.
  • parallelism <avg>/<max> — متوسط عدد خيوط CPU العاملة داخل هذه المرحلة في الوقت نفسه، من أصل الحد الأقصى الذي يمكنها استخدامه. وتشير قيمة قريبة من الحد الأقصى إلى أن المرحلة استُخدم فيها التوازي بكفاءة؛ أما القيمة القريبة من 1 فتعني أنها نُفِّذت في الغالب بشكل تسلسلي.
  • Stage (<stage>) — اسم المرحلة. في الخطوة التي تحتوي على مرحلة واحدة، يُعرَض سطر الوقت مباشرةً من دون تسمية Stage (...). أما الخطوات التي تضم عدة مراحل، فتطبع سطراً معنَّوناً لكل مرحلة؛ فعلى سبيل المثال، يعرض Aggregating السطرين Stage (partial aggregation) وStage (final aggregation)، ويعرض hash join السطرين Stage (build) وStage (probe).
لا يقتصر ClickHouse على موازاة تنفيذ المهام داخل خطوة في الخطة، بل يوازي أيضاً تنفيذ خطوات الخطة نفسها. يعكس مقياس parallelism عمل هذه الخطوة فقط. وقد تعمل خطوات أخرى بالتوازي، لذلك لا يوضح هذا الرقم كيف تقارن درجة التوازي في هذه الخطوة بالاستعلام ككل.
يُحسَب الرقم الأقصى في parallelism بوصفه الحد الأدنى بين:
  1. العدد الإجمالي للمهام داخل خطوة الخطة؛
  2. الحد الأقصى لعدد خيوط معالجة الاستعلام المحدَّد في max_threads.
عند استخدام processors = 1، يُطبَع سطر إضافي أسفل كل مرحلة يوضح توزيع الزمن المنقضي عبر معالجات المرحلة:
يشير <n> إلى عدد المعالِجات في هذه المرحلة. ويشير الفارق الكبير بين median وmax إلى اختلال في توازن الحمل بين المعالِجات المتوازية.

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 مع تلميح لإنشاء فهرس. الصف المجمّع (مرشحون متعددون) عند تقييم مرشحين أو أكثر تجريبيًا، يُضيف EXPLAIN WHATIF كتلة إضافية واحدة باسم (combined: idx_a, idx_b, ...) بعد الصفوف الخاصة بكل مرشح. وتعرض هذه الكتلة الفائدة المشتركة لوجود جميع تلك الفهارس في الوقت نفسه: إذ إن القراءة الفعلية لا تُبقي الحبيبة إلا إذا نجت من كل فهرس تخطٍّ، لذلك يكون التقدير المجمّع هو تقاطع الحبيبات الباقية لدى المرشحين. ومن ثم تكون قيمة skip_ratio فيها على الأقل بقدر أفضل مرشح منفرد — فالفهارس المتكاملة تقلّص معًا بدرجة أكبر، بينما لا تغيّرها الفهارس المتكررة. لا تُسهم إلا المرشحات التي تحمل source: empirical، لأن الصف الموحَّد يُبنى من تقاطع مجموعات البقاء الخاصة بكل granule لكلٍ منها. أما المرشحات المقدَّرة على أنها statistical أو applicability_only فلا تملك بيانات على مستوى granule، لذا تُستبعَد؛ وبناءً على ذلك لا تظهر الكتلة الموحَّدة إلا عندما يكون مرشحان على الأقل قد أنتجا تقديرًا تجريبيًا، وتُحذَف بخلاف ذلك (على سبيل المثال عند empirical = 0). وتكون حقول التقدير فيها مماثلة لحقول كتلة تجريبية خاصة بكل مرشح، باستثناء أن elapsed_us يساوي 0 — إذ إن التقدير الموحَّد مشتق من عمليات المسح الخاصة بكل مرشح، وليس من عملية مسح جديدة. أما الاسم التركيبي (combined: ...) فهو مجرد تسمية في التقرير، ولا يمكن استخدامه مع force_data_skipping_indices. مثال تجريبي
سيؤدي 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
لم تكتمل عملية التحقق، لذا فإن نجاح الاستعلام لا يضمن أن الاستبدال لن يسبب مشكلات.
آخر تعديل في ٢٣ يوليو ٢٠٢٦