غالبًا ما أحتاج إلى تشغيل الاستعلامات مقابل جداول كبيرة لا تحتوي على الفهرس الصحيح. لذا أطلب من DBA لإنشاء مثل هذا المؤشر. أول شيء يفعله هو إلقاء نظرة على إحصائيات الجدول ومعرفة حجم مساحة الفهرس.
غالبًا ما كان يخبرني بإيجاد حل بديل لأن "الفهرس أكبر بالفعل من الجدول". يشعر أن الفهرس يجب أن يكون أصغر من البيانات ، لأنه أخبرني "هل رأيت الفهرس في كتاب من قبل؟ إنه أصغر بكثير من الكتاب نفسه ، وهذه هي الطريقة التي يجب أن يكون بها فهرس الجدول".
لا أشعر أن فلسفته صحيحة ، لكن لا يمكنني أن أتحداه لأنه رائد DBA وأنا مطور. أشعر أنه إذا كان الاستعلام يحتاج إلى فهرس ، فيجب إنشاء الفهرس فقط ، بدلاً من العثور على "حلول" تجعل مقدمي الخدمات الذين لا يمكن قراءتهم ولا يمكن الحفاظ عليهم.
أختار الأعمدة المطلوبة فقط. تكمن المشكلة في أنني أقوم بالتصفية حسب التاريخ ، لذا سيقوم المحرك بالضرورة بإجراء مسح جدول لمطابقة الأعمدة. يتم تشغيل الاستعلام مرة واحدة في اليوم ، ليلاً ، لجمع الإحصائيات ، ولكن يستغرق 15 دقيقة للتشغيل (لدينا قاعدة أخرى صارمة وسريعة: لا يجب أن يستغرق أي إجراء أكثر من 3 دقائق).
أظهر لي DBA إحصائيات الفهرس. كان هناك حوالي 10 فهارس على هذا الجدول ، تم استخدام 6 منها فقط (أظهرت الإحصائيات صفر ضربات إلى 4 منها). هذا نظام كبير يشارك فيه أكثر من 20 مطورًا. تم إنشاء الفهارس لأي سبب من الأسباب ، وربما لم تعد تستخدم.
نحن مطالبون بدعم SQL Server 2008 ، لأن هذا ما تعمل عليه قواعد البيانات التجريبية. لكن العملاء جميعًا في عامي 2014 و 2016.
فكر في تصميم الفهرس مثل مفتاح منزلق. يمكنك تحريك مفتاح التبديل المثلث الأحمر هذا في أي مكان على طول الخط الذي تريده:
أنا عادة لا أقيسها من حيث الحجم - أفكر عادة في ذلك من حيث كمية المؤشر ، ولكن الحجم سيكون جيدًا أيضًا.
يبدو أن DBA الخاص بك يعتقد أن التبديل بعيد جدًا إلى اليمين - حيث أضفت الكثير من الفهارس ، وأن عمليات الحذف/التحديثات/الإدخالات تعمل ببطء شديد.
بدلاً من الجدل حول مكان التبديل ، حاول سؤاله عن مشاكل الأداء التي تواجهها بسبب العدد الكبير من الفهارس. ربما يشكو المستخدمون من سرعة الحذف/التحديث/الإدراج ، أو أنه يرى انتظار القفل ، أو يواجه صعوبة في النسخ الاحتياطي لقاعدة البيانات نظرًا لحجمها.
نقطة البداية هي عادةً 5 و 5: حوالي 5 فهارس لكل جدول ، مع حوالي 5 حقول أو أقل لكل فهرس. لا يوجد شيء سحري في هذا الرقم - إنه يأتي فقط من حقيقة أن لدي 5 أصابع في كل يد ، لذلك من السهل رفع يدي وشرح القاعدة.
قد تحتاج إلى وجود العديد من فهارس LESS أقل من 5 عندما يكون حمل العمل الخاص بك متحيزًا بشدة لعمليات الحذف/التحديث/الإدراج ، وليس لديك ما يكفي من حصانا الأجهزة لمواكبة.
قد تتمكن من الحصول على العديد من فهارس MORE عندما يكون عبء العمل الخاص بك في الغالب للقراءة فقط ، أو عندما تستثمر بشكل كبير في الأجهزة (مثل تخزين قاعدة البيانات بالكامل في الذاكرة ، وتخزين جميع وحدات التخزين ذات الحالة الصلبة أسفلها.)
أنا أحب إجابة برنت وصوتت عليه. أود أن أضيف منظور آخر بالرغم من ذلك. لقد عملت كمستخدم ومطور و DBA وأشعر أن الآراء ليست ذات صلة. أعتقد أن الأمر متروك للمستخدم (أو صاحب المصلحة) لتحديد كيفية أداء الاستعلام والوقت المستغرق للحصول على النتائج. ثم يعود الأمر إلى المطور و DBA للعمل معًا لتحقيق ذلك.
إذا كان منصب DBA في شركتك هو "المسؤول" عن هذا الموضوع ، فيمكنهم تحليل استعلامك وتقديم اقتراحات حول تصميم استعلام أفضل أو الإجابة عن الأداء.
إذا لم يكن بالإمكان تعديل الاستعلام و/أو بنية البيانات لتحقيق الهدف ، فأنا أعتقد أنه يعود إلى ثلاثة خيارات.
بالطبع ، لكل حالة العديد من المتغيرات اعتمادًا على عوامل تجارية وتقنية متعددة ، ولكن أعتقد أن الخيارات الثلاثة تنطبق على معظم الحالات إن لم يكن جميعها.
كما تشير الرغبة في وجود أكثر من فهارس "The Ozar 5" على طاولة على الأرجح إلى أن لديك الكثير من الأنواع المختلفة من الاستعلامات المقروءة على الطاولة.
أي يشير على الأرجح إلى أنه يمكنك الاستفادة من مجموعة متفاوتة أو غير متجمعة فهرس مخزن الأعمدة على الطاولة.
بدلاً من الحصول على الفهرس الأمثل لكل من مسارات الوصول المختلفة لـ N ، يمنحك مخزن الأعمدة مسحًا فائق السرعة والقدرة على تخطي الأعمدة غير الضرورية ، ومقاطع الصف. لذلك يمكنك الحصول على عدد صغير من فهارس BTree للمعاملات بالغة الأهمية ، والعودة إلى متجر الأعمدة لكل شيء آخر.
تم تصميم فهارس متجر الأعمدة للعمل في أحمال عمل OLTP الثقيلة مع SQL Server 2016+. راجع وثائق تحليلات التشغيل في الوقت الفعلي .
يبدو صارمًا جدًا على منع الفهارس> الجدول. إذا كان الجدول الخاص بك نادرًا ما يتغير (أو يتغير في الليل عندما لا يكون هناك منافسة كبيرة على الموارد) ويتم الاستعلام عنه كثيرًا بعدة طرق مختلفة ، يمكن تبرير العديد من الفهارس الكبيرة. يجب أن تحرص DBAs أيضًا على عدم إلصاق أنوفها في الأماكن التي لا تنتمي إليها. إذا أعطاك/نظامك حدًا على الجيجابايت ، فلا يجب أن يهتم كثيرًا بكيفية استخدام هذه المساحة. إذا كان مرهقًا ، فقد يكون هذا هو السبب.
ولكن هناك أشياء كثيرة يجب وضعها في الاعتبار:
where substr(surname, 1, 2) = substr(<userinput>, 1, 2) and surname=<userinput>
) و create index i on customers(substr(surname,1,2))
. قد يكون هذا سريعًا بما يكفي وسيكون فهرسك أصغر.