سؤال

عند محاولة فهم كيفية تنفيذ عبارة SQL، يوصى أحيانًا بالنظر إلى خطة الشرح.ما هي العملية التي يجب على المرء أن يمر بها في تفسير (فهم) خطة الشرح؟ما الذي يجب أن تبرز ، "أوه ، هذا يعمل بشكل رائع؟" مقابل "أوه لا ، هذا ليس صحيحًا".

هل كانت مفيدة؟

المحلول

أرتعد عندما أرى تعليقات تفيد بأن عمليات المسح الكاملة للجداول سيئة وأن الوصول إلى الفهرس جيد.عمليات فحص الجدول الكامل، وفحص نطاق الفهرس، وفحص الفهرس الكامل السريع، والحلقات المتداخلة، ودمج الانضمام، وربط التجزئة، وما إلى ذلك.هي ببساطة آليات الوصول التي يجب أن يفهمها المحلل ودمجها مع معرفة بنية قاعدة البيانات والغرض من الاستعلام من أجل التوصل إلى أي نتيجة ذات معنى.

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

لذلك، بالنسبة لآلية كيفية قراءة خطة الشرح، تعد وثائق أوراكل دليلاً جيدًا: http://download.Oracle.com/docs/cd/B28359_01/server.111/b28274/ex_plan.htm#PFGRF009

استمتع بقراءة جيدة من خلال دليل ضبط الأداء أيضًا.

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

لذا، خلاصة القول:فهم آليات الوصول.فهم قاعدة البيانات.فهم القصد من الاستعلام.تجنب القواعد العامة.

نصائح أخرى

هذا الموضوع كبير جدًا بحيث لا يمكن الإجابة عليه في سؤال مثل هذا.يجب أن تأخذ بعض الوقت للقراءة دليل ضبط الأداء من Oracle

يوضح المثالان أدناه فحصًا كاملاً وفحصًا سريعًا باستخدام الفهرس.

من الأفضل التركيز على التكلفة والأصل.وبالنظر إلى الأمثلة فإن استخدام الفهرس يقلل من تكلفة تشغيل الاستعلام.

إنها أكثر تعقيدًا بعض الشيء (وليس لدي معالجة بنسبة 100٪ لها) ولكن التكلفة في الأساس هي دالة لتكلفة وحدة المعالجة المركزية والإدخال والإخراج، والأصل هو عدد الصفوف التي تتوقع Oracle تحليلها.إن تقليل كلا الأمرين أمر جيد.

لا تنس أن تكلفة الاستعلام يمكن أن تتأثر باستعلامك ونموذج مُحسِّن Oracle (على سبيل المثال:التكلفة والاختيار وما إلى ذلك) وعدد المرات التي تقوم فيها بتشغيل إحصاءاتك.

مثال 1:

المسح http://docs.google.com/a/shanghainetwork.org/File?id=dd8xj6nh_7fj3cr8dx_b

مثال 2 باستخدام الفهارس:

الفهرس http://docs.google.com/a/fukuoka-now.com/File?id=dd8xj6nh_9fhsqvxcp_b

وكما اقترح بالفعل، احترس من TABLE SCAN.يمكنك تجنب هذه بشكل عام.

قد يكون البحث عن أشياء مثل عمليات الفحص التسلسلي مفيدًا إلى حد ما، ولكن الحقيقة تكمن في الأرقام...إلا عندما تكون الأرقام مجرد تقديرات!ما هو عادة بعيد أكثر فائدة من النظر في الاستعلام يخطط ينظر إلى الواقع تنفيذ.في Postgres، هذا هو الفرق بين EXPLAIN وEXPLAIN ANALYZE.يقوم EXPLAIN ANALYZE بتنفيذ الاستعلام فعليًا، ويحصل على معلومات توقيت حقيقية لكل عقدة.يتيح لك ذلك رؤية ما هو في الحقيقة يحدث، بدلا من ما المخطط يعتقد سوف يحدث.ستجد في كثير من الأحيان أن الفحص التسلسلي لا يمثل مشكلة على الإطلاق، بل هو شيء آخر في الاستعلام.

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

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

هناك شيء واحد يجب أخذه في الاعتبار، وهو أن شرح الخطط هو في الواقع أفضل التخمينات.

قد تكون فكرة جيدة أن تتعلم استخدام sqlplus، وتجرب أمر AUTOTRACE.مع بعض الأرقام الصعبة، يمكنك عمومًا اتخاذ قرارات أفضل.

ولكن يجب عليك أن تسأل.فهو يعرف كل شيء عن ذلك :)

يخبرك ناتج الشرح بالمدة التي استغرقتها كل خطوة.أول شيء هو العثور على الخطوات التي استغرقت وقتًا طويلاً وفهم ما تعنيه.تخبرك أشياء مثل الفحص المتسلسل أنك بحاجة إلى فهارس أفضل - فهي في الغالب مسألة بحث في قاعدة البيانات والخبرة الخاصة بك.

غالبًا ما تكون عبارة "أوه لا، هذا ليس صحيحًا" على شكل أ مسح الجدول.لا تستخدم عمليات فحص الجدول أي فهارس خاصة ويمكن أن تساهم في تطهير كل ما هو مفيد في ذاكرة التخزين المؤقت للذاكرة.في PostgreSQL، على سبيل المثال، ستجد الأمر يبدو هكذا.

Seq Scan on my_table  (cost=0.00..15558.92 rows=620092 width=78)

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

في الأساس، عليك إلقاء نظرة على كل عملية ومعرفة ما إذا كانت العمليات "منطقية" نظرًا لمعرفتك بكيفية عملها.

على سبيل المثال، إذا كنت تقوم بضم جدولين، A وB في العمودين الخاصين بهما C وD (A.C=B.D)، وتعرض خطتك فحص فهرس مجمع (مصطلح SQL Server - غير متأكد من مصطلح Oracle) في الجدول A، ثم تنضم حلقة متداخلة إلى سلسلة من الفهارس المجمعة التي تبحث عنها في الجدول B، قد تعتقد أن هناك مشكلة.في هذا السيناريو، قد تتوقع أن يقوم المحرك بإجراء زوج من عمليات فحص الفهرس (فوق الفهارس الموجودة في الأعمدة المرتبطة) متبوعة بربط دمج.قد يكشف المزيد من الاستقصاء عن إحصائيات سيئة تجعل المُحسِّن يختار نمط الانضمام هذا، أو فهرسًا غير موجود بالفعل.

انظر إلى النسبة المئوية للوقت المستغرق في كل قسم فرعي من الخطة، وفكر في ما يفعله المحرك.على سبيل المثال، إذا كان يقوم بمسح جدول، فكر في وضع فهرس على الحقل (الحقول) الذي يتم البحث عنه

أنا أبحث بشكل أساسي عن عمليات فحص الفهرس أو الجدول.يخبرني هذا عادةً أنني أفتقد فهرسًا في عمود مهم موجود في بيان المكان أو بيان الانضمام.

من http://www.sql-server-performance.com/tips/query_execution_plan_analogy_p1.aspx:

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

* Index or table scans: May indicate a need for better or  additional indexes.
* Bookmark Lookups: Consider changing the current clustered index,
  consider using a covering index, limit
  the number of columns in the SELECT
  statement.
* Filter: Remove any functions in the WHERE clause, don't include wiews
  in your Transact-SQL code, may need
  additional indexes.
* Sort: Does the data really need to be sorted? Can an index be used to
  avoid sorting? Can sorting be done at
  the client more efficiently? 

ليس من الممكن دائمًا تجنبها ، ولكن كلما تمكنت من تجنبها ، سيكون أداء الاستعلام الأسرع.

من البديهيات

(ربما ترغب في قراءة التفاصيل أيضًا:

سيء

مسح الجدول لعدة جداول كبيرة

جيد

باستخدام مؤشر فريد
يتضمن الفهرس كافة الحقول المطلوبة

الفوز الأكثر شيوعا

في حوالي 90% من مشكلات الأداء التي رأيتها، يكون الفوز الأسهل هو تقسيم استعلام يحتوي على الكثير (4 أو أكثر) من الجداول إلى استعلامين أصغر وجدول مؤقت.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top