pt-visual-explainp - عبر الإنترنت في السحابة

برنامج:

اسم

pt-visual -شرح - تنسيق الإخراج شرح كشجرة.

موجز

الاستخدام: pt-visual -شرح [الخيارات] [الملفات]

يقوم pt-visual -شرح بتحويل إخراج EXPLAIN إلى تمثيل شجرة لخطة الاستعلام.
إذا تم إعطاء FILE ، تتم قراءة الإدخال من الملف (الملفات). بدون FILE ، أو عندما يكون FILE هو - ، اقرأ
المدخلات القياسية.

أمثلة:

شرح pt-visual

pt- شرح مرئي-ج

mysql -e "شرح تحديد * من mysql.user" | شرح pt-visual

المخاطر

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

· اقرأ وثائق الأداة

· مراجعة الأداة المعروفة "BUGS"

· اختبار الأداة على خادم غير إنتاجي

· قم بعمل نسخة احتياطية لخادم الإنتاج الخاص بك وتحقق من النسخ الاحتياطية

الوصف

pt-visual -شرح إخراج شرح MySQL للمهندسين العكسيين في خطة تنفيذ الاستعلام ،
والتي يتم تنسيقها بعد ذلك كشجرة في عمق اليسار - بنفس الطريقة التي يتم بها تمثيل الخطة في الداخل
MySQL. من الممكن القيام بذلك يدويًا ، أو قراءة إخراج EXPLAIN مباشرةً ، ولكن ذلك
يتطلب الصبر والخبرة. كثير من الناس يجدون تمثيل شجرة أكثر
مفهوم.

يمكنك توجيه الإدخال إلى شرح pt-visual- أو تحديد اسم ملف في سطر الأوامر ،
بما في ذلك اسم الملف السحري "-" ، والذي سيتم قراءته من الإدخال القياسي. يمكن أن تفعل اثنين
الأشياء مع المدخلات: قم بتحليلها لشيء يشبه إخراج EXPLAIN ، أو الاتصال
إلى مثيل MySQL وتشغيل EXPLAIN على الإدخال.

عند تحليل المدخلات الخاصة به ، يفهم pt-visual-illustration ثلاثة تنسيقات: جدولي من هذا القبيل
معروض في عميل سطر أوامر mysql ، عموديًا مثل ذلك الذي تم إنشاؤه باستخدام سطر \ G
إنهاء في عميل سطر الأوامر mysql ، وفصل علامة التبويب. يتجاهل أي خطوط عليه
لا يعرف كيف يحلل.

عند تنفيذ الإدخال ، يستبدل pt-visual-illustration كل شيء في الإدخال حتى ملف
حدد الكلمة الأساسية أولاً مع "EXPLAIN SELECT" ، ثم ينفذ النتيجة. يجب عليك أن
حدد "--connect" لتنفيذ الإدخال كاستعلام.

في كلتا الحالتين ، فإنه يبني شجرة من مجموعة النتائج ويطبعها إلى الإخراج القياسي. ل
الاستعلام التالي ،

اختر * من sakila.film_actor انضم إلى sakila.film باستخدام (film_id) ؛

ينشئ pt-visual -شرح خطة الاستعلام هذه:

الانضمام
+ - بحث المرجعية
| + - الجدول
| | الجدول film_actor
| | ممكن_المفاتيح idx_fk_film_id
| + - بحث الفهرس
| مفتاح film_actor-> idx_fk_film_id
| ممكن_المفاتيح idx_fk_film_id
| مفتاح_لين 2
| المرجع sakila.film.film_id
| الصفوف 2
+ - مسح الجدول
الصفوف 952
+ - الجدول
فيلم الجدول
محتمل_مفاتيح أساسية

خطة الاستعلام عبارة عن بحث عميق على اليسار ، وعمق أولاً ، وجذر الشجرة هو عقدة الإخراج -
الخطوة الأخيرة في خطة التنفيذ. بمعنى آخر ، اقرأها على النحو التالي:

1. قم بمسح جدول "الفيلم" الذي يصل إلى ما يقدر بـ 952 صفاً.

2. لكل صف ، ابحث عن صفوف متطابقة عن طريق إجراء بحث فهرس في
film_actor-> idx_fk_film_id index بالقيمة من sakila.film.film_id ، ثم a
البحث عن الإشارات المرجعية في جدول film_actor.

لمزيد من المعلومات حول كيفية قراءة إخراج شرح ، يرجى مراجعة
<http://dev.mysql.com/doc/en/explain.html> ، وهذا الحديث بعنوان "محسن استعلام MySQL
الداخلي والميزات القادمة في الإصدار 5.2 ": من Timour Katchaounov ، أحد MySQL
المطورين:http://goo.gl/VIWvo>

MODULES

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

تقبل حزمة ExplainParser سلسلة وتوزع ما تعتقد أنه يبدو
اشرح الإخراج منه. الملخص كالتالي:

تتطلب "pt-visual-illustration" ؛
my $ p = ExplainParser-> new () ؛
صفوفي $ = $ p-> تحليل ("بعض النصوص") ؛
الصفوف # $ مصفوفة من hashrefs.

تقبل حزمة ExplainTree مجموعة من الصفوف وتحولها إلى شجرة. للراحة،
يمكنك أيضًا جعله يفوض إلى ExplainParser ويقوم بتحليل النص نيابة عنك. هنا هو
ملخص:

تتطلب "pt-visual-illustration" ؛
my $ e = ExplainTree-> new () ؛
شجرة $ الخاصة بي = $ e-> تحليل ("بعض النصوص" ، \٪ خيارات) ؛
مخرجاتي $ = $ e-> pretty_print (شجرة $) ؛
طباعة شجرة $؛

الخوارزمية

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

يمكن بناء الشجرة عن طريق فحص أعمدة المعرف والنوع والجدول لكل صف.
إليك ما أعرفه عنهم:

عمود المعرف هو الرقم التسلسلي للتحديد. هذا لا يشير إلى التعشيش. هو - هي
يأتي فقط من حساب SELECT من يسار عبارة SQL. إنه مثل الالتقاط
الأقواس في التعبير النمطي. لا يحتوي صف نتيجة الاتحاد على معرف ، لأنه
ليس SELECT. يشير كود المصدر في الواقع إلى UNIONs على أنه fake_lex ، على ما أذكر.

إذا كان هناك صفان متجاوران لهما نفس قيمة المعرف ، فسيتم ربطهما بالمفردة القياسية-
اكتساح طريقة الانضمام المتعدد.

يخبر العمود select_type أ) أنه تم فتح نطاق فرعي جديد ب) ما هو نوع
علاقة الصف بالصف السابق ج) نوع العملية التي يمثلها الصف.

تعني كلمة SIMPLE عدم وجود استفسارات فرعية أو اتحادات في الاستعلام بأكمله.

· PRIMARY يعني أن هناك ، ولكن هذا هو التحديد الأبعد.

· [تابع] الاتحاد يعني أن هذه النتيجة متحدة مع النتيجة السابقة (وليس صفًا ؛ أ
قد تشمل النتيجة أكثر من صف واحد).

· إنهاء UNION RESULT مجموعة من النتائج الموحدة.

· [DEPENDENT | UNCACHEABLE] SUBQUERY يعني فتح نطاق فرعي جديد. هذا هو النوع
من الاستعلام الفرعي الذي يحدث في عبارة WHERE أو قائمة SELECT أو غير ذلك ؛ لا يعود
ما يسمى ب "الجدول المشتق".

· DERIVED هو استعلام فرعي في عبارة FROM.

تحتوي جميع الجداول التي تم الانضمام إليها على نفس نوع select. على سبيل المثال ، إذا انضممت إلى ثلاثة
الجداول الموجودة داخل استعلام فرعي تابع ، ستقول جميعها نفس الشيء: استعلام تابع.

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

أخيرًا ، الترتيب مهم. إذا كان معرف الصف أقل من الذي قبله ، أعتقد أن هذا يعني
إنها تعتمد على شيء آخر غير الذي قبلها. على سبيل المثال،

شرح تحديد
(اختر 1 من sakila.film) ،
(اختر 2 من sakila.film_actor) ،
(اختر 3 من sakila.actor) ؛

| معرف | select_type | الجدول |
+ ---- + ------------- + ------------ +
| 1 | الابتدائية | NULL |
| 4 | طلب | ممثل |
| 3 | طلب | عامل_فيلم |
| 2 | طلب | فيلم |

إذا كانت النتائج بالترتيب 2-3-4 ، أعتقد أن هذا يعني أن 3 هو استعلام فرعي من 2 ، 4 هو أ
استعلام فرعي للعدد 3. وهذا يعني أن 4 عبارة عن استعلام فرعي لأقرب صف حديث سابق
بمعرف أصغر ، وهو 1. وبالمثل لـ 3 و 2.

يصعب بناء هذا الهيكل برمجيًا في شجرة لنفس السبب الذي يجعله صعبًا
لفهمها عن طريق الفحص: هناك مراجع للأمام والخلف.
هو مرجع أمامي لـ selectN ، بينما هو مرجع خلفي إلى selectM و
حدد هذا يجعل من الصعب الحصول على خوارزميات العودية وغيرها من خوارزميات بناء الأشجار بشكل صحيح (ملاحظة:
بعد التنفيذ ، أرى الآن كيف سيكون من الممكن التعامل مع كل من الأمام و
مراجع متخلفة ، لكن ليس لدي دافع لتغيير شيء يعمل). يعتبر
ما يلي:

اختر من (
اختر 1 من sakila.actor كممثل_1
الاتحاد
اختر 1 من sakila.actor كممثل_2
) كـ der_1
الاتحاد
اختر من (
اختر 1 من sakila.actor كممثل_3
اتحاد كل شيء
اختر 1 من sakila.actor كممثل_4
) كـ der_2 ؛

| معرف | select_type | الجدول |
+ ------ + -------------- + ------------ +
| 1 | الابتدائية | |
| 2 | مشتق | ممثل_1 |
| 3 | الاتحاد | ممثل_2 |
| NULL | نتيجة الاتحاد | |
| 4 | الاتحاد | |
| 5 | مشتق | ممثل_3 |
| 6 | الاتحاد | ممثل_4 |
| NULL | نتيجة الاتحاد | |
| NULL | نتيجة الاتحاد | |

سيكون من الأسهل كثيرًا التعامل معه إذا بدا مثل هذا (لقد وضعت أقواسًا بين قوسين على المعرف
الصفوف التي قمت بنقلها):

| معرف | select_type | الجدول |
+ ------ + -------------- + ------------ +
| [1] | نتيجة الاتحاد | |
| 1 | الابتدائية | |
| [2] | نتيجة الاتحاد | |
| 2 | مشتق | ممثل_1 |
| 3 | الاتحاد | ممثل_2 |
| 4 | الاتحاد | |
| [5] | نتيجة الاتحاد | |
| 5 | مشتق | ممثل_3 |
| 6 | الاتحاد | ممثل_4 |

في الواقع ، لماذا لا تعيد ترقيم جميع المعرفات ، بحيث يصبح الصف الأساسي 2 ، وهكذا؟ الذي - التي
ستجعل القراءة أسهل. لسوء الحظ ، سيكون لذلك تأثير
تدمير معنى عمود المعرف ، والذي أعتقد أنه من المهم الحفاظ عليه في
الشجرة النهائية. أيضًا ، على الرغم من أنه يسهل القراءة ، إلا أنه لا يجعله أسهل
التلاعب برمجيًا ؛ لذلك لا بأس من تركها مرقمة كما هي.

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

السؤال التالي هو كيفية العثور على الصف الأخير الذي يجب أن يكون عقدة فرعية لـ UNION أو
مشتق. سأبدأ بـ DERIVED ، لأن الحل يجعل الاتحاد سهلاً.

ضع في اعتبارك كيف تقوم MySQL بترقيم SELECTs بالتتابع وفقًا لموقعها في ملف
SQL ، من اليسار إلى اليمين. نظرًا لأن الجدول DERIVED يرفق كل شيء بداخله في نطاق
يصبح جدولًا مؤقتًا ، فهناك شيئان فقط يجب التفكير فيهما: الاستعلامات الفرعية التابعة له
والنقابات (إن وجدت) ، وإخوتها التالية في النطاق الذي يحيط بها. أطفالها
ستحتوي جميعها على معرف أكبر مما هو عليه ، بحكم التعريف ، لذا فإن أي صفوف لاحقة ذات نطاق أصغر
معرف إنهاء النطاق.

هنا مثال. يحتوي الجدول المشتق الأوسط هنا على استعلام فرعي و UNION لجعله ملف
أكثر تعقيدًا على سبيل المثال.

شرح حدد 1
من (
حدد film_id من sakila.film Limit 1
) كـ der_1
ينضم (
حدد film_id، ممثل_id، (حدد العدد (*) من sakila.rental) كـ r
من sakila.film_actor الحد 1
اتحاد كل شيء
اختر 1 ، 1 ، 1 من sakila.film_actor كدمية
) كـ der_2 باستخدام (film_id)
ينضم (
حدد معرف الفاعل من sakila.actor الحد 1
) كـ der_3 باستخدام (ممثل_ معرف) ؛

هذا هو ناتج شرح:

| معرف | select_type | الجدول |
| 1 | الابتدائية | |
| 1 | الابتدائية | |
| 1 | الابتدائية | |
| 6 | مشتق | ممثل |
| 3 | مشتق | عامل_فيلم |
| 4 | طلب | تأجير |
| 5 | الاتحاد | دمية |
| NULL | نتيجة الاتحاد | |
| 2 | مشتق | فيلم |

جميع الأشقاء لديهم هوية 1 ، والوسط الذي أهتم به مشتق 3. (لاحظ MySQL
لا يتم تنفيذها بالترتيب الذي حددته لهم ، وهو أمر جيد). لاحظ الآن أن MySQL
يطبع الصفوف بالترتيب المعاكس الذي حددته للاستعلامات الفرعية: 6 ، 3 ، 2. دائمًا
يبدو أنه يفعل ذلك ، وقد تكون هناك طرق أخرى لإيجاد حدود النطاق
بما في ذلك البحث عن الحد الأدنى للأخ الأكبر التالي ، ولكن هذا أمر جيد
ما يكفي من مجريات الأمور. أجد نفسي مضطرًا إلى الاعتماد عليه في طلبات البحث الفرعية غير المشتقة ، لذلك أعتمد عليه
هنا ايضا. لذلك ، قررت أن كل شيء أكبر من أو يساوي 3 ينتمي إلى
النطاق المشتق.

قاعدة UNION بسيطة: فهي تستهلك نطاق التضمين بأكمله ، وتجد ملف
الأجزاء المكونة لكل جزء ، ستجد بداية كل جزء كما هو مشار إليه في ملف
التعريف ، ونهايته إما قبل التالي مباشرة ، أو إذا كانت
الجزء الأخير ، النهاية هي نهاية النطاق.

هذا بسيط فقط لأن UNION تستهلك النطاق بأكمله ، والذي يكون إما بأكمله
بيان ، أو نطاق جدول مشتق. هذا لأن الاتحاد لا يمكن أن يكون شقيقًا
لاتحاد آخر أو طاولة ، مشتقة أم لا. (جرب كتابة مثل هذا البيان إذا لم تفعل
انظر إليه بشكل حدسي). لذلك ، يمكنك فقط العثور على حدود النطاق المضمن ، و
الباقي سهل. لاحظ في المثال أعلاه أن الاتحاد قد انتهى ، أيّ
يتضمن الصف مع المعرف 4 - ويشمل كل صف بين 3 و 5.

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

شرح
حدد معرّف_الممثل ،
(
حدد العدد (film_id)
+ (اختر العد (*) من sakila.film)
من sakila.film انضم إلى sakila.film_actor باستخدام (film_id)
حيث يوجد (
اختر * من sakila.actor
حيث sakila.actor.actor_id = sakila.film_actor.actor_id
)
)
من sakila.actor.

| معرف | select_type | الجدول |
| 1 | الابتدائية | ممثل |
| 2 | طلب | فيلم |
| 2 | طلب | عامل_فيلم |
| 4 | طلب تابع | ممثل |
| 3 | طلب | فيلم |

بالترتيب ، يجب أن تُبنى الشجرة على النحو التالي:

· انظر الصف 1.

· انظر الصف 2. إنه معرف أعلى من 1 ، لذلك فهو استعلام فرعي ، إلى جانب كل صف آخر
الذي معرفه أكبر من 2.

· داخل هذا النطاق ، انظر 2 و 2 وانضم إليهم. انظر 4. إنها معرف أعلى من 2 ، لذلك
إنه استعلام فرعي مرة أخرى ؛ يعيد تنفيذ. بعد ذلك ، انظر 3 ، وهو أيضًا أعلى ؛ يعيد تنفيذ.

لكن السبب الوحيد لعدم احتواء الاستعلام الفرعي المتداخل على التحديد 3 هو أن التحديد 4 جاء
أولاً. بعبارة أخرى ، إذا بدا "شرح" هكذا ،

| معرف | select_type | الجدول |
| 1 | الابتدائية | ممثل |
| 2 | طلب | فيلم |
| 2 | طلب | عامل_فيلم |
| 3 | طلب | فيلم |
| 4 | طلب تابع | ممثل |

سأضطر إلى الافتراض عند رؤية التحديد 3 أن التحديد 4 هو استعلام فرعي منه ، بدلاً من ذلك
من مجرد كونك الأخ التالي في النطاق المرفق. إذا كان هذا خطأ من أي وقت مضى ، ثم
الخوارزمية خاطئة ، ولا أرى ما يمكن فعله حيال ذلك.

UNION أكثر تعقيدًا من مجرد "النطاق بأكمله هو اتحاد" ، لأن
قد تكون UNION نفسها داخل نطاق مُرفق يُشار إليه فقط بالعنصر الأول
داخل الاتحاد. هناك ثلاثة أنواع فقط من النطاقات المرفقة: UNION و DERIVED و
طلب. لا يمكن لاتحاد أن يحيط اتحادًا ، ولدى DERIVED "علامات نطاق" خاصة به ، لكن أ
يمكن لـ SUBQUERY إحاطة UNION بالكامل ، مثل هذا المثال الغريب في الجدول الفارغ t1:

شرح حدد * من t1 حيث لا يوجد (
(حدد t11.i من t1 t11) union (حدد t12.i من t1 t12)) ؛

| معرف | select_type | الجدول | إضافي |
+ ------ + -------------- + ------------ + -------------- ------------------ +
| 1 | الابتدائية | t1 | صف ثابت غير موجود |
| 2 | طلب | NULL | لا توجد جداول مستخدمة |
| 3 | طلب | NULL | لا يوجد صف مطابق في جدول ثابت |
| 4 | الاتحاد | t12 | صف ثابت غير موجود |
| NULL | نتيجة الاتحاد | | |

قد تجعل المراجع السابقة لـ UNION الأمر يبدو كما لو أن UNION تُرفق الاستعلام الفرعي ،
لكن دراسة الاستعلام توضح أن هذا ليس هو الحال. لذلك عندما يكون صف الاتحاد الأول
يقول SUBQUERY ، إنها هذه الحالة الخاصة.

بالمناسبة ، لا أفهم تمامًا خطة الاستعلام هذه ؛ هناك 4 مرقمة SELECT في
خطة ، ولكن 3 فقط في الاستعلام. الأقارب حول الاتحادات ذات مغزى. إزالة
ستجعل الشرح مختلفًا. من فضلك قل لي كيف ولماذا يعمل هذا إذا كنت تعرف.

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

تطبع MySQL الصفوف بترتيب التنفيذ ، حتى المراجع الأمامية والخلفية. في
في أي نطاق محدد ، تتم معالجة الصفوف كشجرة بعمق يسار. MySQL لا تعمل "كثيف"
خطط التنفيذ. يبدأ بجدول ، ويجد صفًا مطابقًا في الجدول التالي ، و
يستمر حتى الجدول الأخير ، عندما يصدر صفًا. عندما ينفد ، يتراجع حتى
يمكنه العثور على الصف التالي ويكرر. هناك خفايا بالطبع ، ولكن هذا هو
الخطة الأساسية. هذا هو السبب في أن MySQL تحول جميع الوصلات الخارجية الصحيحة إلى صلات خارجية و
لا يمكن أن تفعل FULL OUTER JOIN.

هذا يعني في أي نطاق معين ، على سبيل المثال

| معرف | select_type | الجدول |
| 1 | بسيط | tbl1 |
| 1 | بسيط | tbl2 |
| 1 | بسيط | tbl3 |

تبدو خطة التنفيذ وكأنها اجتياز العمق أولاً لهذه الشجرة:

الانضمام
/ \
الانضمام إلى tbl3
/ \
الجدول 1 tbl2

قد لا يكون JOIN هو JOIN. قد يكون استعلامًا فرعيًا ، على سبيل المثال. هذا يأتي من
اكتب عمود شرح. تقول الوثائق أن هذا هو "نوع الصلة" ، لكنني أعتقد أن "الوصول"
النوع "أكثر دقة ، لأنه" كيفية وصول MySQL إلى الصفوف. "

يزين pt-visual-illustration الشجرة بشكل ملحوظ أكثر من مجرد تحويل الصفوف إلى عقد.
قد تحصل كل عقدة على سلسلة من التحولات التي تحولها إلى شبكة فرعية من أكثر من واحدة
العقدة. على سبيل المثال ، يجب أن يقوم مسح الفهرس الذي لم يتم تمييزه بـ "استخدام الفهرس" بالبحث عن إشارة مرجعية
في صفوف الجدول هذه شجرة فرعية ثلاثية العقد. ومع ذلك ، بعد ترتيب العقد أعلاه
وتحديد النطاق ، فإن بقية العملية بسيطة جدًا.

OPTIONS

تقبل هذه الأداة وسيطات سطر أوامر إضافية. الرجوع إلى "SYNOPSIS" والاستخدام
المعلومات للحصول على التفاصيل.

- مهمة تمرير
المطالبة بكلمة مرور عند الاتصال بـ MySQL.

- شارست
شكل قصير: -A ؛ النوع: سلسلة

مجموعة الأحرف الافتراضية. إذا كانت القيمة utf8 ، فقم بتعيين binmode Perl في STDOUT إلى utf8 ،
يمرر الخيار mysql_enable_utf8 إلى DBD :: mysql ، ويقوم بتشغيل SET NAMES UTF8 بعد
الاتصال بـ MySQL. أي قيمة أخرى تعين binmode على STDOUT بدون طبقة utf8 ،
وتشغيل SET NAMES بعد الاتصال بـ MySQL.

- العنقودية pk
افترض أن عمليات الوصول إلى فهرس PRIMARY KEY لا تحتاج إلى إجراء بحث عن إشارة مرجعية لاستردادها
صفوف. هذا هو الحال بالنسبة لشركة InnoDB.

- تكوين
النوع: صفيف

اقرأ قائمة ملفات التكوين المفصولة بفواصل ؛ إذا تم تحديد ذلك ، يجب أن يكون هذا هو الأول
الخيار في سطر الأوامر.

--الاتصال
تعامل مع المدخلات كاستعلام ، واحصل على إخراج EXPLAIN عن طريق الاتصال بمثيل MySQL
وتشغيل شرح على الاستعلام. عندما يتم إعطاء هذا الخيار ، يستخدم pt-visual-illustration
الخيارات الأخرى الخاصة بالاتصال مثل "--user" للاتصال بـ MySQL
مثال. إذا كان لديك ملف .my.cnf ، فسوف يقرأه ، لذلك قد لا تحتاج إلى تحديد
أي خيارات خاصة بالاتصال.

--قاعدة البيانات
شكل قصير: -D ؛ النوع: سلسلة

اتصل بقاعدة البيانات هذه.

- ملف الافتراضات
شكل قصير: -F ؛ النوع: سلسلة

اقرأ فقط خيارات mysql من الملف المحدد. يجب أن تعطي اسم مسار مطلق.

--صيغة
اكتب: سلسلة ؛ الافتراضي: شجرة

ضبط تنسيق الإخراج.

الافتراضي هو شجرة مقتضبة مطبوعة بشكل جيد. القيم الصالحة هي:

معنى القيمة
===== =============================================== ===
شجرة شجرة مقتضبة مطبوعة بشكل جميل.
تفريغ البيانات :: إخراج Dumper (انظر البيانات :: Dumper للمزيد).

--مساعدة
إظهار المساعدة والخروج.

--مضيف
شكل قصير: -h ؛ النوع: سلسلة

اتصل بالمضيف.

--كلمه السر
شكل قصير: -p ؛ النوع: سلسلة

كلمة المرور لاستخدامها عند الاتصال. إذا كانت كلمة المرور تحتوي على فاصلات ، فيجب تخطيها
بشرطة مائلة للخلف: "exam \، ple"

--معرّف
النوع: سلسلة

قم بإنشاء ملف PID المحدد. لن تبدأ الأداة إذا كان ملف PID موجودًا بالفعل و
معرف المنتج الذي يحتوي عليه يختلف عن معرف المنتج الحالي. ومع ذلك ، إذا كان ملف PID
موجود ولم يعد PID الذي يحتويه قيد التشغيل ، وستقوم الأداة بالكتابة فوق PID
ملف مع PID الحالي. تتم إزالة ملف PID تلقائيًا عند خروج الأداة.

--ميناء
شكل قصير: -P ؛ النوع: int

رقم المنفذ المراد استخدامه للاتصال.

- مجموعة فارز
النوع: صفيف

قم بتعيين متغيرات MySQL في هذه القائمة المفصولة بفواصل لأزواج "المتغير = القيمة".

بشكل افتراضي ، تحدد الأداة:

wait_timeout = 10000

تتجاوز المتغيرات المحددة في سطر الأوامر هذه الإعدادات الافتراضية. على سبيل المثال،
يؤدي تحديد "--set-vars wait_timeout = 500" إلى تجاوز القيمة الافتراضية البالغة 10000.

تقوم الأداة بطباعة تحذير وتستمر في حالة عدم إمكانية تعيين متغير.

--قابس كهرباء
أشكال قصيرة؛ النوع: سلسلة

ملف مأخذ التوصيل لاستخدامه.

--المستعمل
شكل قصير: -u ؛ النوع: سلسلة

مستخدم لتسجيل الدخول إذا لم يكن المستخدم الحالي.

--الإصدار
عرض الإصدار والخروج.

DSN OPTIONS

تُستخدم خيارات DSN هذه لإنشاء DSN. يتم إعطاء كل خيار مثل "الخيار = القيمة".
تعتبر الخيارات حساسة لحالة الأحرف ، لذا فإن P و p ليستا نفس الخيار. لا يمكن أن يكون هناك
مسافة بيضاء قبل أو بعد "=" وإذا كانت القيمة تحتوي على مسافة بيضاء ، فيجب ذكرها.
تكون خيارات DSN مفصولة بفواصل. راجع صفحة دليل مجموعة أدوات percona للحصول على التفاصيل الكاملة.

· أ

dsn: محارف ؛ نسخ: نعم

مجموعة الأحرف الافتراضية.

· د

dsn: قاعدة بيانات ؛ نسخ: نعم

قاعدة البيانات الافتراضية.

F

dsn: mysql_read_default_file ؛ نسخ: نعم

اقرأ الخيارات الافتراضية من الملف المحدد فقط

· ح

dsn: مضيف ؛ نسخ: نعم

اتصل بالمضيف.

· ص

dsn: كلمة المرور ؛ نسخ: نعم

كلمة المرور لاستخدامها عند الاتصال. إذا كانت كلمة المرور تحتوي على فاصلات ، فيجب تخطيها
بشرطة مائلة للخلف: "exam \، ple"

· ص

dsn: منفذ ؛ نسخ: نعم

رقم المنفذ المراد استخدامه للاتصال.

· س

dsn: mysql_socket ؛ نسخ: نعم

ملف مأخذ التوصيل لاستخدامه.

· ش

dsn: مستخدم ؛ نسخ: نعم

مستخدم لتسجيل الدخول إذا لم يكن المستخدم الحالي.

البيئة

متغير البيئة "PTDEBUG" يتيح إخراج التصحيح المطول إلى STDERR. لتمكين
تصحيح الأخطاء والتقاط جميع المخرجات في ملف ، قم بتشغيل الأداة مثل:

PTDEBUG = 1 نقطة-مرئية-شرح ...> ملف 2> & 1

كن حذرًا: إخراج التصحيح ضخم ويمكن أن يولد عدة ميغا بايت من المخرجات.

نظام المتطلبات

أنت بحاجة إلى Perl و DBI و DBD :: mysql وبعض الحزم الأساسية التي يجب تثبيتها في أي
إصدار جديد معقول من لغة Perl.

استخدم pt-visual-illustrationp عبر الإنترنت باستخدام خدمات onworks.net