كيفية تحسين الأداء على المؤشر المجمع البحث

StackOverflow https://stackoverflow.com/questions/1971045

سؤال

أحاول تحسين الأداء على استعلام يعمل ببطء شديد. بعد المرور من خلال خطة التنفيذ الفعلية; ؛ لقد وجدت أن أ فهرس المجموعات تسعى كان يأخذ 82 ٪. هل هناك أي طريقة بالنسبة لي لتحسين الأداء على فهرس السعي؟ فيما يلي صورة للمشكلة فهرس السعي من خطة التنفيذ وكذلك الفهرس والجدول الذي يستخدمه.

alt text http://img340.imageshack.us/img340/1346/seek.png

فِهرِس:

/****** Object:  Index [IX_Stu]    Script Date: 12/28/2009 11:11:43 ******/
CREATE CLUSTERED INDEX [IX_Stu] ON [dbo].[stu] 
(
 [StuKey] ASC
)WITH (PAD_INDEX  = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF) ON [PRIMARY]

الجدول (تم حذف بعض الأعمدة للإيجاز):

CREATE TABLE [dbo].[stu](
 [StuCertKey] [int] IDENTITY(1,1) NOT NULL,
 [StuKey] [int] NULL
 CONSTRAINT [PK_Stu] PRIMARY KEY NONCLUSTERED 
(
 [StuCertKey] ASC
)WITH (PAD_INDEX  = OFF, IGNORE_DUP_KEY = OFF, FILLFACTOR = 80) ON [PRIMARY]
) ON [PRIMARY]
هل كانت مفيدة؟

المحلول

أنا أعمل هنا ، لكن ...

يسعى المؤشر المجمع ، في معظمه ، إلى أفضل السيناريو. الطرق الوحيدة التي يمكنني التفكير فيها لتحسين الأداء هي:

  • قم بتحديث الاستعلام لإرجاع عدد أقل من الصفوف/الأعمدة ، إن أمكن ؛
  • إزالة الجدل أو إعادة بناء الفهرس ؛
  • قسم الفهرس عبر أقراص/خوادم متعددة.

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

نصائح أخرى

يحدث المؤشر المجمع عند استخدام الفهارس غير المقيدة وليست سيئة بالضرورة.

النظر في الاستعلام التالي:

SELECT s.StuKey, s.Name, s.Address, s.City, s.State FROM stu s WHERE State='TX'

إذا كان هناك فهرس مجمعة فقط على Stukey ، فإن SQL Server لديه خيار واحد فقط ، فيجب عليه مسح الجدول بأكمله يبحث عن صفوف حيث state = "tx 'وإرجاع تلك الصفوف.

إذا قمت بإضافة فهرس غير متكامل على الحالة 

CREATE INDEX IX_Stu_State on Stu (State)

الآن SQL Server لديه خيار جديد. يمكن أن تختار البحث عن استخدام الفهرس غير المتواصل ، والذي سيحدث الصفوف حيث الحالة = "tx". ومع ذلك ، من أجل الحصول على الأعمدة المتبقية للعودة في SELECT ، يجب أن تبحث عن تلك الأعمدة من خلال القيام بفهرس متجمع عن كل صف.

إذا كنت ترغب في تقليل الفهرس المجمع ، فيمكنك جعل الفهرس "يغطي" من خلال تضمين أعمدة إضافية فيه.

 CREATE INDEX IX_Stu_State2 on Stu (State) INCLUDE (name, address, city )

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

نطاق المؤشر المجمع يبحث عن إرجاع 138 صفًا ليس مشكلتك.

من الناحية الفنية ، يمكنك تحسين أداء Seek من خلال جعل الفهرس المجمع أضيق:

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

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

أفكار...

  • لماذا يتم تجميع IX_STU؟ داخليًا ، يضيف SQL Server 4 بايت "فريد من نوعه" إلى فهارس غير متجانسة غير متوفرة. ما هو التبرير؟ هذا أيضًا يتفجر على PK أيضًا

  • ما هو الاستعلام الفعلي الذي تديره؟

  • أخيرًا ، لماذا FillFactor 80 ٪؟

يحرر:

  • سيكون FillFactor "الطبيعي" 90 ٪ ، ولكن هذه قاعدة واحدة فقط

  • 11 انضمام استعلام؟ هذه على الأرجح مشكلتك. ما هي انضمامك ، أين البنود وما إلى ذلك؟ ما هي خطة النص الكاملة؟

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

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

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

هل جربت بعض الصيانة على هذا الفهرس؟ مثل إلغاء تجاهله؟ يبدو غريباً حقًا أنه يكلف كثيرًا (120.381). INDEX SEEP هو أسرع عملية فهرس ، يجب ألا يستغرق هذا الوقت. هل يمكنك نشر الاستعلام؟

ماذا يحدث إذا كنت تتدحرج أين المعايير ، مثل هذا:

SELECT StuCertKey, StuKey FROM stu 
WHERE stuKey in (/* list 50 values of StuKey here */)

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

لاحظ أن SELECT * يمكن أن تكون بطيئة للغاية إذا كان هناك العديد من الأعمدة الكبيرة ، وخاصة إذا كانت هناك نقط.

تحقق من فهرس الإحصائيات.

سيؤدي إعادة حساب إحصائيات المؤشر المجمع إلى حل المشكلة.

في حالتي ، كنت أبحث عن 30 سجلًا في 40 مترًا تم استترداده. تقول خطة التنفيذ إنها تمر عبر المؤشر المجمع ولكنها استغرقت حوالي 200 مللي ثانية. ولم يكن الفهرس مقلوبًا. بعد إعادة حسابها إحصائيات ، يتم إنجازها تحت 10 مللي ثانية!

إعادة بناء الفهرس ، وحساب الإحصائيات؟

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

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