مزايا تحديد HASH JOIN على مجرد إجراء JOIN؟

Question

ما هي المزايا، إن وجدت، لإجراء HASH JOIN بشكل صريح عبر JOIN العادي (حيث سيقرر SQL Server أفضل استراتيجية JOIN)؟على سبيل المثال:

select pd.*
from profiledata pd
inner hash join profiledatavalue val on val.profiledataid=pd.id

في نموذج التعليمات البرمجية المبسط أعلاه، أقوم بتحديد استراتيجية JOIN، بينما إذا تركت الكلمة الأساسية "التجزئة"، فسيقوم SQL Server بإجراء MERGE JOIN خلف الكواليس (وفقًا لـ "خطة التنفيذ الفعلية").

Answer 1

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

سأترك الأمر بمفرده ما لم يكن لديك استعلام معقد للغاية أو كميات هائلة من البيانات حيث لا يمكنه ببساطة إنتاج خطة جيدة.ثم سأفكر في الأمر.

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

أنا شخصياً لم أحدد مطلقًا تلميح JOIN في أي كود إنتاج.

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

لقد رأيت مطورين آخرين يستخدمونها ولكن فقط عندما كانت لديهم طرق عرض معقدة متداخلة مع طرق عرض معقدة وتسببوا في حدوث مشكلات لاحقة عندما أعادوا البناء.

يحرر:

لقد أجريت تحويلاً اليوم حيث سيستخدمها بعض الزملاء لفرض خطة استعلام سيئة (مع NOLOCK وMAXDOP 1) "لتشجيع" الترحيل بعيدًا عن طرق العرض المتداخلة المعقدة القديمة التي يستدعيها أحد أنظمة المصب مباشرة.

Answer 2

متى تجرب تلميح التجزئة، ماذا عن:

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

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

لماذا تستخدم أي تلميحات صلة (تجزئة/دمج/حلقة مع تأثير جانبي لأمر القوة)؟

• لتجنب التنفيذ البطيء للغاية (.5 -> 10.0 ثانية) لحالات الزاوية.
• عندما يختار المحسن باستمرار خطة متواضعة.

من المحتمل أن يكون التلميح المقدم غير مثالي لبعض الظروف ولكنه يوفر أوقات تشغيل يمكن التنبؤ بها بشكل أكثر اتساقًا.يجب اختبار أسوأ السيناريوهات المتوقعة وأفضل السيناريوهات مسبقًا عند استخدام التلميح.تعد أوقات التشغيل التي يمكن التنبؤ بها أمرًا بالغ الأهمية لخدمات الويب حيث يُفضل استعلام اسمي محسّن بشكل صارم [.3s، .6s] على استعلام يمكن أن يتراوح بين [.25، 10.0s] على سبيل المثال.يمكن أن تحدث اختلافات كبيرة في وقت التشغيل مع الإحصائيات التي تم تحديثها حديثًا واتباع أفضل الممارسات.

عند الاختبار في بيئة تطوير، يجب على المرء إيقاف تشغيل "الغش" أيضًا لتجنب الفروق في وقت التشغيل الساخن/البارد.من جهة اخرى بريد...

CHECKPOINT -- flushes dirty pages to disk
DBCC DROPCLEANBUFFERS -- clears data cache
DBCC FREEPROCCACHE -- clears execution plan cache

قد يكون الخيار الأخير هو نفس تلميح الخيار (إعادة الترجمة).

يمكن أن يحدث MAXDOP وتحميل الجهاز أيضًا فرقًا كبيرًا في وقت التشغيل.يعد تجسيد CTE في جداول مؤقتة أيضًا آلية قفل جيدة وشيء يجب مراعاته.

Answer 3

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

Answer 4

التلميح الوحيد الذي رأيته في رمز الشحن هو الخيار (الأمر الإجباري).قد يؤدي الخطأ الغبي في مُحسِّن استعلام SQL إلى إنشاء خطة حاولت الانضمام إلى varchar غير مفلتر ومعرف فريد.أدت إضافة أمر FORCE إلى تشغيل عامل التصفية أولاً.

أعلم أن التحميل الزائد على الأعمدة أمر سيء.في بعض الأحيان، عليك أن تتعايش معها.

Answer 5

لا يضمن لك مُحسِّن الخطة المنطقية أنه وجد الحل الأمثل:الخوارزمية الدقيقة بطيئة جدًا بحيث لا يمكن استخدامها في خادم الإنتاج؛بدلا من ذلك يتم استخدام بعض الخوارزميات الجشعة.

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