هل من السيء أن يكون لديك مساحة فهرس أكبر من مساحة البيانات؟
غالبًا ما أحتاج إلى تشغيل الاستعلامات مقابل جداول كبيرة لا تحتوي على الفهرس الصحيح. لذا أطلب من 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)). قد يكون هذا سريعًا بما يكفي وسيكون فهرسك أصغر. - تدعم قواعد البيانات أنواع مختلفة من الفهارس. تستخدم بعض الأنواع مساحة أقل من الأنواع الأخرى. ربما يمكن تحويل بعض الفهارس الخاصة بك إلى نوع أقل استهلاكًا للمساحة؟ تأكد أولاً من فهم أنواع الفهرس المختلفة والمواقف التي تكون جيدة وسيئة بالنسبة لها.
- إذا كانت مهمة الدُفعة غير المتكررة هي الشيء الوحيد الذي يحتاج إلى فهرس محدد ، ففكر في إنشاء هذا الفهرس لمهمة الدُفعة هذه فقط وإسقاطه بعد ذلك.