پست تنها



ایندکس¬گذاری و افزایش سرعت

برای آغاز کار و پیدا کردن یک درک مناسب از ایندکس ­گذاری، اساسی ­ترین گام آشنایی با نحوه ­ی ذخیره اطلاعات در یک بانک اطلاعاتی اس

اطلاعات چگونه در SQL Server ذخیره می­ شوند؟

اطلاعات در SQL Server در دو نوع فایل .mdf و .ldf ذخیره می¬شوند. فایل .mdf حاوی داده¬ها، جداول و عناصر بانک اطلاعاتی (فایل داده) و فایل .ldf حاوی اطلاعات تراکنش¬های انجام شده روی بانک اطلاعاتی (فایل تراکنش) است. تصویر ۱۳-۱ را ببینید.

اطلاعات موجود در فایل¬های داده، در قالب Page های هشت کیلوبایتی ذخیره می¬شوند. هر هشت Pageی که در کنار هم قرار می¬گیرند به¬عنوان یک Extent شناخته می¬شوند. در تصویر ۱۳-۲ می¬توانید ساختار کلی یک Page را ببینید.

جالب است بدانید SQL Server هربار که برای خواندن اطلاعات به یک Page مراجعه می¬کند، مجبور است کل اطلاعات آن را بخواند. بنابراین هرچه اطلاعات موجود در یک Page بیشتر باشد و فضای خالی کمتری داشته باشد، سرعت دسترسی به اطلاعات بیشتر خواهد بود. به این معنی که SQL Server با خواندن تعداد Pageهای کمتر، اطلاعات بیشتری را می¬تواند دریافت کند و این نکته¬ای است که در طراحی جداول می¬تواند مورد بررسی قرار گیرد.

هر Page همیشه از سه بخش تشکیل شده است (تصویر ۱۳-۲ را ببینید)¬:

هر Page همیشه از سه بخش تشکیل شده است

بخش اول Page Header است. معمولا طول این بخش ۹۶ بایت است و اطلاعاتی مانند: Page Id و Object Id و … را نگه¬داری می¬کند.

بخش دوم Payload نامیده می¬شود که وظیفه¬ی ذخیره اطلاعات جدول را برعهده دارد. از آنجایی که ۹۶ بایت فضا برای بخش Header در نظر گرفته شده است، از ۸۱۹۲ بایت (هشت کیلوبایت) فضای کل Page، ۸۰۹۶ بایت برای این بخش در اختیار شما قرار خواهد گرفت.

بخش سوم و آخر در یک Page، Row Offset Array است. این بخش به ازای هر سطر (رکورد) اطلاعات دو بایت فضا برای نشان¬دادن محل قرارگیری اطلاعات شما در Page ذخیره می¬کند. این بخش به ایندکس¬گذاری شما کمک خواهد کرد.

وقتی با ساختار کلی ذخیره¬سازی اطلاعات در SQL Server آشنا شدید، می¬توانید به بحث ایندکس¬ها بپردازید.
. آشنایی با جداول بدون ایندکس یا Heap

 

برای درک اهمیت ایندکس ­گذاری بهتر است در ابتدای کار با ساختار جداولی که بدون هیچ­گونه ایندکس ­گذاری، ایجاد می­ شوند آشنا شوید. در این صورت با روش دستیابی SQL Server به اطلاعات این گونه از جداول آشنا خواهید شد.


یک فروشگاه مواد غذایی را در نظر بگیرید. کالاهای موجود در این فروشگاه به همان ترتیبی که صاحب فروشگاه آن را خریداری کرده است در قفسه¬ها قرار گرفته¬اند. اگر صاحب فروشگاه در هر بار خرید، تعدادی ماکارونی خریداری کند، شما می¬توانید ماکارونی¬ها را در بخش¬های مختلف فروشگاه پیدا کنید. چرا که در هربار خریدی که صاحب فروشگاه برای پر کردن اجناس فروشگاه انجام می¬دهد ماکارونی¬ها پس از آخرین کالاهای قرارگرفته در قفسه¬ها قرار می¬گیرند. با این تعریف شاید انتظار فروشگاهی مانند تصویر ۱۳-۳ را داشته باشید.

تصویر ۱۳-۳٫

جداول Heap جداولی هستند که هیچ¬گونه ایندکس¬گذاری¬ای در آنها انجام نشده است. اطلاعات به همان ترتیبی که در این جدول قرار می¬گیرند، در Pageها ذخیره و نگه¬داری می¬شوند و این بدان معنی است که ذخیره¬سازی اطلاعات بدون هرگونه مرتب¬سازی¬ای انجام می¬شود

اگر نگاه دقیقی به تصویر ۱۳-۳ بیندازید، خواهید دید که این فروشگاه ۴ ویژگی دارد که با اولین نگاه می¬توان آنها را دریافت:

۱- کالاها به صورت توده¬ای در کنار یکدیگر قرارگرفته¬اند.

۲- فروشگاه هیچ نظم خاصی ندارد.

۳- هیچ کس از محل دقیق قرارگیری یک کالا مطلع نیست.

۴- برای جست¬وجو و به¬دست آوردن یک نوع کالا، باید تمام فروشگاه را جست¬وجو کرد.

آیا استفاده از چنین فروشگاه¬هایی به صرفه است؟ و آیا به¬راحتی و به سرعت می¬توانید در این فروشگاه نیازهای خود را تامین کنید؟ حتما پاسخ شما به این دو سوال منفی خواهد بود.

ساختار جداولی که در SQL Server بدون ایندکس¬گذاری ایجاد می¬شوند نیز می¬تواند تا حد بسیار زیادی به این فروشگاه نزدیک باشد. به این نوع جداول Heap گفته می¬شود. جدول نمایش داده شده در تصویر ۱۳-۴ یک جدول Heap است.

تصویر ۱۳-۴٫

همانطور که در تصویر ۱۳-۴ نشان داده شده است، این جدول نیز تمام خصوصیات فروشگاهی که پیش از این بیان شد را دارد و هیچ اثری از نظم و ترتیب در هیچ¬کدام از ستون¬های این جدول به¬چشم نمی¬خورد. SQL Server برای به¬دست آوردن یا به عبارتی جست¬وجوی یک داده مجبور می¬شود کل رکوردهای این جدول را جست¬وجو کند (به این کار در اصطلاح Scan گفته می¬شود). جست¬وجو کردن کل رکوردهای جدول به معنی جست¬وجوی کل Pageهای مربوط به این جدول خواهد بود.

به چهار دلیل زیر استفاده از جداول Heap در ساختار بانک اطلاعاتی پروژه¬ها توصیه نمی¬شوند چراکه در بانک¬های اطلاعاتی مشکل آفرین و هزینه¬بر خواهند بود:

۱- اطلاعات در Page ها بدون هیچ ترتیبی ذخیره می¬شوند.

۲- SQL Server برای جست¬وجوی یک داده، تمام Pageهای جدول را جست¬وجو می¬کند.

۳- منابع زیادی از SQL Server را هدر می¬دهد.

۴- در عمل Replication، نمی¬توان این جداول را Replicate کرد.

ساخت یک جدول Heap:

Create Table tblPerson (
	Id int,
	NationalId varchar (10) not null, 
	Name nvarchar (30) not null, 
	Family nvarchar (35) not null, 
	Phone varchar (10) null, 
	Address nvarchar (max) null) 
<span data-mce-type="bookmark" style="display: inline-block; width: 0px; overflow: hidden; line-height: 0;" class="mce_SELRES_start"></span>

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

Join Our Newsletter Today On The Writers Cookbook

Stay updated with all latest updates,upcoming events & much more.
مشترک شدن
SUBSCRIBE NOW
close-link