استراتژی های ایندکس گذاری (چه فیلدهایی مناسب ایندکس هستند)

مقدمه

ایندکس گذاری پایگاه داده یک هنر است که در آن پایگاه داده همان پرده ای است که روی آن نقاشی می کنیم و ایندکس ها نقاشی های روی آن هستند. این دو با هم یک نقاشی زیبا از ذخیره سازی و کارایی خلق می کنند. کمی رنگ در این طرف، کمی رنگ در آن طرف و نقاشی ها اشیاء را شکل می دهند. این تشابه را با زمانی مقایسه کنید که یک کلاستر ایندکس (Clustered Index) روی جدول و تعداد کمی نانکلاستر ایندکس (Non-Clustered Index) منجر به افزایش کارایی می شود. این افزایش در کارایی به زیبایی خلق یک شاهکار می باشد. اگر کمی روی ایندکس ها کار کنید ممکن است احساس خوبی به شما دست بدهد، اما مسئله ی کارایی به شما اجازه می دهد که بدانید این فعالیت کم آنقدرها مفید نیست که ما مثال رنگ آمیزی و خلق تصویر زیبا را برای آن بیان کردیم.

کارایی به شما می گوید که دانش و جزییات زیادی در طراحی ایندکس ها وجود دارد، این مسئله به نحوی است که می توانیم بگوییم اگر کسی روی موضوع ایندکس گذاری تسلط دارد و درک اساسی و مفهومی از مسئله پیدا کرده است و از ایندکس گذاری به صورت بهینه استفاده می کند، او واقعاً یک هنرمند است. اینکه چند ستون را به خاطر اینکه این ها خوب در کنار هم کار می کنند کنار هم قرار دهیم و جدول خوبی طراحی کنیم، نسبت به اینکه ایندکس مناسبی انتخاب کنیم، بازده کمتری دارد. ایندکس هایی که مبتنی بر تلاش زیاد و تمرین صحیح هستند بهترین راه حل می باشند. در ادامه ی این سرفصل آموزشی الگوهایی را ارائه می دهیم که بوسیله ی آن بتوان ایندکس های مناسب را شناسایی کرد.

Heaps

موارد خاصی وجود دارد که استفاده از جداول Heap کار صحیحی است. اکثر DBAها یک قانون کلی دارند: همه ی جداول در پایگاه داده باید به جای اینکه Heap باشند از Clustered Index استفاده کنند. با وجود اینکه این قانون، قانون درستی است اما حالت هایی هم وجود دارد که استفاده از heap قابل قبول است. در این قسمت به تنها یکی از سناریوها اشاره می کنیم. بقیه ی موارد نیاز به یک بحث مفصل دارد که در سرفصل های آینده به آن اشاره می شود.یک قانون کلی این است: اینکه به طور واضح و مشخص بگوییم کجا می توانیم از heap به جای Clustered Index استفاده کنیم کاری دشوار است. ( در ادامه مفصل بحث می کنیم.)

Temporary Objects

یکی از حالاتی که heap ارجحیت دارد استفاده از آن در اشیاء موقت مانند جداول موقت و متغیرهای از نوع جدول می باشد. وقتی از این اشیا استفاده می کنیم، اصلاً به فکر ایجاد ایندکس روی آن ها نبوده ایم. بنابراین تعداد heapهایی که استفاده می کنید بیشتر از چیزی است که فکر می کردید.

آخرین باری را که یک شیء موقت یا یک متغیر جدول ایجاد کردید را به لحظه ای به خاطر آورید. آیا از سینتکس های مربوط به ایندکس یا کلید اصلی در آن استفاده کرده اید؟ اگر جواب خیر است، شیء موقت شما یک heap است. در مثالی در ادامه نشان می دهیم که کارایی یک شیء موقت با heap یا clustered index تفاوت چندانی ندارند و می توان از آن چشم پوشی کرد.

برای این مثال، اجازه دهید با یک سناریو برای جدول موقت کار را شروع کنیم. در این مثال ما از جدول Sales و SalesOrderHeader استفاده می کنیم و بر اساس SalesPersonID رکوردهایی را واکشی و سپس در جدول موقتمان درج می کنیم. سپس از جدول موقت برای استفاده از رکوردهای درج شده در آن استفاده می کنیم. به دو صورت مثال را اجرا می کنیم تا نشان دهیم استفاده از heap یا clustered index اینجا تفاوتی ایجاد نمی کند.

در اولین نسخه ی مثال که در زیر نشان داده شده است، جدول موقت یک جدول heap است. این متدی است که اغلب افراد موقع ایجاد جدول موقت از آن استفاده می کنند. همانگونه که شکل مربوط به execution plan نشان می دهد، وقتی جدول موقت استفاده شد، (همانگونه که فلش قرمز نشان می دهد) یک اسکن روی جدول انجام می شود تا به رکوردهای داخل جدول دستیابی شود. این رفتاری است که از یک heap انتظار می رود. از آن جایی که رکوردها مرتب نیستند، راهی وجود ندارد که یک ردیف خاص را بدون اینکه تمام رکورد ها را بررسی کنیم واکشی کنیم.
برای یافتن همه ردیف هایی که در Sales.SealesOrderDetail قرار گرفته اند و با رکوردهای داخل جدول موقت منطبق هستند، execution plan از یک حلقه ی تو در تو به همراه index seek استفاده می کند.

USE AdventureWorks2012
GO
CREATE TABLE #TempWithHeap
(
SalesOrderID INT
);
INSERT INTO #TempWithHeap
SELECT SalesOrderID
FROM Sales.SalesOrderHeader
WHERE SalesPersonID = 283;
SELECT sod.* FROM Sales.SalesOrderDetail sod
INNER JOIN #TempWithHeap t ON t.SalesOrderID = sod.SalesOrderID;
GO