أنواع EXPLAIN
AST— شجرة البنية النحوية المجردة.SYNTAX— نص الاستعلام بعد التحسينات على مستوى AST.QUERY TREE— شجرة الاستعلام بعد التحسينات على مستوى شجرة الاستعلام.PLAN— خطة تنفيذ الاستعلام.PIPELINE— مسار تنفيذ الاستعلام.ANALYZE— ينفّذ الاستعلام ويُرفق بخطة التنفيذ مقاييس وقت التشغيل المقاسة.ESTIMATE— العدد التقديري للصفوف والعلامات والأجزاء التي ستُقرأ من الجداول أثناء معالجة الاستعلام.TABLE OVERRIDE— النتيجة التي تم التحقق من صحتها لتجاوز جدول على مخطط دالة الجدول.
EXPLAIN AST
SELECT فقط.
الإعدادات:
graph– يطبع AST على شكل رسم بياني موصوف بلغة وصف الرسوم البيانية DOT. القيمة الافتراضية: 0.
EXPLAIN SYNTAX
oneline– يطبع الاستعلام في سطر واحد. القيمة الافتراضية:0.run_query_tree_passes– يشغّل تمريرات شجرة الاستعلام قبل إخراج شجرة الاستعلام. القيمة الافتراضية:0.query_tree_passes– إذا كانrun_query_tree_passesمضبوطًا، فإنه يحدّد عدد التمريرات التي سيتم تشغيلها. ومن دون تحديدquery_tree_passes، يتم تشغيل جميع التمريرات.single_record– يعيد الاستعلام المعاد تنسيقه كسجل واحد متعدد الأسطر بدلًا من سجل واحد لكل سطر. القيمة الافتراضية:1(يتحكم فيه الإعدادexplain_syntax_single_record). اضبطه على0لاستعادة الإخراج السابق بسجل واحد لكل سطر، أو اضبطexplain_syntax_single_record = 0(عموميًا أو ضمنSETTINGSلكل استعلام)، أو اضبطcompatibilityعلى أي إصدار أقدم من26.8.
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.matches— فيEXPLAIN ANALYZE، يجعل خطوات الربط تُجري أعمال التتبع الإضافية اللازمة لمقاييسmatchedوmatch rateوfanoutفي الحالات التي لا يمكن فيها اشتقاق هذه الأرقام من ناتج الربط نفسه. وحيثما أمكن اشتقاقها، يُبلّغ عنها دون هذا الخيار. راجع خطوات الربط. القيمة الافتراضية: 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 بوصفه الحد الأدنى بين:- العدد الإجمالي للمهام داخل خطوة الخطة؛
- الحد الأقصى لعدد خيوط معالجة الاستعلام المحدَّد في
max_threads.
خطوات الربط
EXPLAIN ANALYZE أسطر المشاركة لكل جانب — Left وRight — ثم أي أسطر خاصة بتنفيذ الربط. يقابل Left وRight الجانبين المنطقيين في SQL. في معظم الحالات، يكون Left أيضًا جانب الفحص في الربط، بينما يكون Right جانب البناء. لكن ليس هذا هو الحال دائمًا بسبب التبديل الذي قد يحدث أثناء تنفيذ الربط. تُغطّى جميع قيم join_algorithm (hash، parallel_hash، grace_hash، partial_merge، full_sorting_merge، parallel_full_sorting_merge، direct)، وكذلك التنفيذان اللذان لا يمكن للإعداد اختيارهما: ربط CROSS أو COMMA، وأي قسم ON لا يحتوي على مساواة مفتاح، ومحرك الجدول Join. يُبلّغ معظمها عن كلا الجانبين، بينما يُبلّغ بعضها فقط عن الجانب الذي يجسّده ماديًا (على سبيل المثال، يطبع direct Left: فقط).
تشترك الأسطر الخاصة بكل جانب في البنية نفسها:
EXPLAIN ANALYZE ما يلي:
rows <rows>— العدد الإجمالي لصفوف ذلك الجانب التي مرّت عبر عملية الربط.matched <matched_rows>— عدد صفوف ذلك الجانب التي وجدت شريك ربط واحدًا على الأقل في الجانب الآخر. يحسب هذا الصفوف لا المفاتيح: إذا ظهر مفتاح ثلاث مرات في الجانب الأيمن وطابق، تُحسب الصفوف الثلاثة في الجانب الأيمن كلها كصفوف متطابقة.match rate <match_rate>%— النسبة المئوية لصفوف ذلك الجانب التي تطابقت، وتُحسب كالتالي:100 * <matched_rows> / <rows>.fanout <fanout>— عدد صفوف الإخراج التي ينتجها، في المتوسط، كل صف متطابق من ذلك الجانب.
not collected بدلًا من 0. يُشتق كل من match rate وfanout من matched، لذا يعرض الجانب الذي لا تتوفر لديه قيمة matched القيم الثلاث كلها باعتبارها not collected.
Fanout
fanout مدى تضاعف الصفوف:
NULL لكل صف في الجانب المحفوظ لم يجد صفًا مطابقًا. وتُطرح هذه الصفوف حتى لا تؤثر سلبًا في النسبة. ولا توجد إلا في جانب محفوظ: الجانب الأيمن في RIGHT وFULL، والجانب الأيسر في LEFT وFULL:
fanout = 0— لم تُنتج الصفوف المتطابقة أي صف إخراج مطلقًا، وهذا ما يفعله ربطANTI: إذ لا يُنتج إلا الصفوف التي لم تجد صفًا مطابقًا.fanout = 1— ربط نظيف بنسبة 1:1؛ إذ أنتج كل صف متطابق صف إخراج واحدًا بالضبط.fanout > 1— ربط بنسبة 1:N؛ إذ ضاعفت المفاتيح المكررة في الجانب الآخر عدد الصفوف. وتشير قيمة كبيرة في كلا الجانبين في الوقت نفسه إلى تضخم ديكارتي غير مقصود.
عندما تتطلب الأرقام matches = 1
EXPLAIN ANALYZE العادي. أما البقية فتتطلب تتبعًا إضافيًا لا يجريه الربط لولا ذلك، لذا لا تُعرض إلا مع EXPLAIN ANALYZE matches = 1. ويعتمد ذلك على الخوارزمية؛ ففي عائلة التجزئة توجد حالتان:
- الجانب الأيمن من
ALL INNERوALL LEFT، إذ يتطلب الأمر وضع علامة على كل صف أيمن متطابق؛ - الجانب الأيسر من
ALL LEFTوALL FULL، ولكن فقط عندما لا يختار الاستعلام شيئًا من الجدول الأيمن ويكون قسمONمساواة بسيطة للمفاتيح. بخلاف ذلك، يسجل الفحص بالفعل الصفوف اليسرى المتطابقة — إما لتجسيد الأعمدة اليمنى أو لتقييم الشرط المتبقي — ويكون العدد دقيقًا دون هذا الخيار.
partial_merge إليه للجانب الأيمن من أنواع ALL الأربعة، للسبب نفسه.
وتحتاج full_sorting_merge وparallel_full_sorting_merge إليه لكلا الجانبين في أنواع ANY. أما
أنواع ALL فلا تحتاج إليه.
يكون الخيار معطّلًا افتراضيًا لأن التتبع الإضافي ليس بلا تكلفة، وتتمثل تكلفته في دقة القياس. يُنفَّذ العمل داخل حلقة الفحص ويزداد مع عدد صفوف الإخراج. استخدم
matches = 1 عندما تحتاج إلى معرفة التطابقات الدقيقة التي وجدتها الصفوف اليسرى واليمنى في الجانب المقابل.matches = 1 كل تركيبة قابلة للجمع. فالجانب الذي يستطيع الربط الإبلاغ عنه يتحدد
بما يتعين على ذلك الربط تنفيذه على أي حال، لذا يعتمد على الخوارزمية، وكذلك على النوع
والصرامة.
عائلة التجزئة. تتفق hash وparallel_hash وgrace_hash دائمًا فيما بينها:
يكون الجانب الأيمن غير متاح كلما احتفظ الربط بصف واحد فقط لكل مفتاح في جدول التجزئة، كما تفعل عمليات الربط
ANY وSEMI وANTI: إذ لا تُخزَّن الصفوف اليمنى المكررة أصلًا، فلا يمكن عدّها. ويكون الجانب الأيسر غير متاح عندما يمنع الربط إخراج صف أيسر سبق أن استحوذ صف أيسر آخر على صفه المقابل، مما يجعل الصفوف الناتجة أقل من الصفوف المتطابقة.
يحوّل تمكين any_join_distinct_right_table_keys ANY إلى دلالات RightAny الأقدم، التي تُنتج صفًا واحدًا لكل صف أيسر، ومن ثم تحافظ على كلا العددين. عندها يُبلّغ ANY RIGHT وANY FULL عن كلا الجانبين، ويُعاد كتابة ANY INNER إلى SEMI LEFT.
يتبع محرك الجدول Join الجدول نفسه، باستخدام النوع والصرامة المعلنين في المحرك: يُبلّغ Join(ALL, INNER, …) عن كلا الجانبين، بينما لا يُبلّغ Join(ANY, LEFT, …) عن أي منهما.
خوارزميات الدمج. تقبل full_sorting_merge وparallel_full_sorting_merge أنواع ALL الأربعة، وANY INNER وANY LEFT وANY RIGHT وASOF وASOF LEFT. وتُبلّغان عن كلا الجانبين لكل نوع باستثناء ASOF وASOF LEFT، حيث يكون الجانب الأيمن not collected، ومن دون الحاجة إلى matches = 1 — إذ تمرّان على الإدخالين المرتبين وتريان كل صف ضمن نطاق متساوٍ أثناء معالجته، لذا لا حاجة إلى إعادة بناء أي شيء لاحقًا.
تقبل partial_merge كلاً من ALL INNER وALL LEFT وALL RIGHT وALL FULL وANY INNER وANY LEFT وSEMI LEFT. وتُبلّغ عن كلا الجانبين لأنواع ALL الأربعة، لكن الجانب الأيمن يتطلب matches = 1؛ أما في ANY INNER وANY LEFT وSEMI LEFT فالجانب الأيمن هو not collected.
direct. الجانب الأيسر فقط. فالجانب الأيمن مخزن مفاتيح-قيم لا يُجسَّد أبدًا في صورة صفوف، لذا لا يحتوي على سطر Right: مطلقًا.
CROSS وCOMMA وON ثابت. لا يُجمع أي من الجانبين، كما هو موضح أعلاه.
عندما تُرجع خوارزميتان رقمًا، تكون الأرقام متطابقة. تمتلك خوارزميات الدمج معلومات إضافية فحسب، لكنها لا تختلف في تعريف ما يُعدّ تطابقًا.
الأسطر الخاصة بالخوارزمية
hash وparallel_hash، ولمحرك الجدول Join، يصف السطر Hash table: جدول التجزئة المُنشأ من الجدول الأيمن:
unique keys <unique_keys>— عدد المفاتيح الفريدة المخزّنة في جدول التجزئة أثناء مرحلة البناء.memory <peak_memory>— ذروة الذاكرة التي استخدمها جدول التجزئة أثناء مرحلة البناء.
grace_hash، يعرض السطر Hash table: أيضًا كيفية تكيّف الربط مع حد الذاكرة، بينما يبيّن السطر Spill: ما إذا كانت البيانات قد نُقلت إلى القرص:
buckets <buckets>— عدد الحاويات التي استقر عليها ربط grace hash join عند انتهاء التنفيذ. يكون هذا العدد دائمًا قوة للعدد2.rehashes <rehashes>— عدد المرات التي تعيّن فيها مضاعفة عدد الحاويات ليتناسب مع حد الذاكرة.Spill:— رايةyes/noتشير إلى ما إذا حدثت أي عملية ترحيل إلى القرص. عند حدوث ذلك، يُظهرleft spilled <left_spilled_bytes>وright spilled <right_spilled_bytes>عدد البايتات المضغوطة المُرحَّلة من الجانبين الأيسر (probe) والأيمن (build)؛ وإذا لم يُرحَّل شيء، يكون السطر ببساطةSpill: no.
partial_merge، يحمل السطر Right: معلومات إضافية حول كيفية تخزين الجدول الأيمن مؤقتًا وفرزه، ويُعرض وقت الفرز في السطرين Stage (build) وStage (probe):
size <right_size>— حجم الذاكرة الذي تشغله كتل الجدول الأيمن.blocks <right_blocks>— عدد الكتل التي خُزِّن فيها الجدول الأيمن مؤقتًا.storage <in-memory|external>— ما إذا كان الجدول الأيمن يتسع في الذاكرة (in-memory) أو كان يجب ترحيله إلى القرص (external). عندما تكون القيمةexternal، يعرض الحقل الإضافيspilled <spilled_bytes>عدد البايتات المضغوطة المكتوبة على القرص.sort time <sort_time>— الوقت المستغرق في فرز الجدول الأيمن (في مرحلة البناء) وكل كتلة واردة من الجانب الأيسر (في مرحلة الفحص).sort share <sort_share>%— قيمةsort timeكنسبة من وقت انشغال تلك المرحلة نفسها (مجموع الوقت المنقضي لمعالجاتها)، بخلاف النسبة المئوية لـtimeالخاصة بالمرحلة، التي تمثل حصة من وقت تنفيذ الاستعلام بأكمله.
full_sorting_merge، لا تُطبع سوى السطور المشتركة Left: وRight:.
بالنسبة إلى ربط direct، لا يُطبع سوى السطر Left:، لأن الجانب الأيمن مخزن مفتاح-قيمة يُبحث فيه مباشرةً بدلًا من تحويله إلى صفوف.
بالنسبة إلى ربط CROSS أو COMMA، ولأي قسم ON دون مساواة مفتاح، يصف السطر Buffer: كيفية الاحتفاظ بالجدول الأيمن في الذاكرة، ويعرض السطر Spill: ما إذا كان قد رُحِّل إلى القرص:
memory <peak_memory>— ذروة الذاكرة التي استهلكها الجدول الأيمن المُخزَّن مؤقتًا.compressed <yes|no>— ما إذا كانت كتلة واحدة مخزَّنة مؤقتًا على الأقل قد ضُغطت؛ وفي هذه الحالة تفكّ القارئات ضغط كل كتلة مخزَّنة.Spill:— علامةyes/noنفسها المستخدمة معgrace_hash، ويعرضright spilled <right_spilled_bytes>عدد البايتات المضغوطة المكتوبة على القرص.
matched not collected: إذ إن المسند الثابت إما يقرن كل صف من الجدول الأيسر بكل صف من الجدول الأيمن، أو لا يقرن أي صف منها، لذا لا يمكن تحديد الصفوف الفردية التي تطابقت.
في عملية ربط مع محرك الجدول Join، يُبلّغ عن كلا الجانبين، إلى جانب السطر Hash table: الذي يصف الجدول المُنشأ مسبقًا. ويعرض الجانب الأيمن عدد الصفوف المخزنة في المحرك، لا صفوف عملية بناء خاصة بكل query.
الأوقات لكل معالِج
processors = 1، يُطبَع سطر إضافي أسفل كل مرحلة يوضح توزيع الزمن المنقضي عبر معالجات المرحلة:
<n> إلى عدد المعالِجات في هذه المرحلة. ويشير الفارق الكبير بين median وmax إلى اختلال في توازن الحمل بين المعالِجات المتوازية.
EXPLAIN ESTIMATE
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— تقدير لعدد البايتات المقروءة، مشتق من متوسط حجم الصف في الجدول، لذا فهو تقريبي ويتفاوت حسب التخزين والضغط. لا يظهر سطر خط الأساس إلا عندما يقرأ الاستعلام صفوفًا؛ ولا يظهر السطر الخاص بكل مرشح إلا عندما يكون تقدير بايتات خط الأساس معروفًا.
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
Query
Query
Response
لم تكتمل عملية التحقق، لذا فإن نجاح الاستعلام لا يضمن أن الاستبدال لن يسبب مشكلات.