برای نشان دادن اهمیت شاخصها، دو پرس و جو برروی یک جدول اجرا و زمان بندی گردید. تنها تفاوت میان تستها آن است که اولین پرس و جو به شاخص اصلی باز می گشت و پرس و جوی دومی به هیچ شاخصی ارجاع نمی یافت. این پرس و جو در اینجا آمده است:
Select * from CALL_TRN where ID > ‘0000022670’
برای جستجو روی شاخص اصلی، آن جدول در فرهنگ داده ها بخاطر داشتن شاخصی برای فیلد شناسه (ID) تعریف گردید و فایل داده های فیزیکی از آن فیلد شناسه (ID) به عنوان کلید اولیه استفاده کرد. قبل از اجرای آن پرس و جو، برای دومین بار، فرهنگ داده ها تغییر کرد)اصلاح شد( درنتیجه شاخص جدول از یک فیلد متفاوتی استفاده کرد. فایل داده های فیزیکی همچنین بازنویسی شد درنتیجه فیلد شناسه (ID) به عنوان کلید تعیین نگردید. نتایج در اینجا ذکر شده اند:
پرس و جو روی فیلد شاخص شده: 0.25 ثاینه
پرس و جو روی فیلد شاخص نشده: 14.71 ثانیه
این بدین معناست که پرس و جوی شاخص شده 5884 درصد سریعتر از پرس و جوی شاخص نشده بوده. کاملا گیرا است، اینطور نیست؟ ذکر این موضوع که پرس و جو ساخته شده مخصوصا برای ارائه تفاوت زیاد در مواقع نتیجه گیری، امری بسیار ارزشمند است. به عبارت دیگر، پیشرفتهای سطح کارائی همواره در رنج شش هزار درصدی نمی باشد، آن تا حد زیادی براساس پرس و جو و داده های مورد بحث می تواند تغییر نماید. برای این مثال، پرس و جوی برگزیده (select query) تنها رکوردهایی را برمی گرداند که شناسه رکورد record ID) بزرگتر از ‘0000022670’ باشد.
به هنگام جستجو کردن در فایل داده ها، آن بر می گرداند این را که فقط 239 رکورد از بین 48،145 رکورد مطابق با این معیارند. یعنی اینکه آن پرس و جو تنها یک دوم از یک درصد رکوردها را برمی گرداند، یک مقدار نسبتا کم. چون پرس و جوی شاخص شده می تواند مستقیما به رکوردهای موجود در فایل داده ها که مطابق با این معیارند پرش کند، از این رو، آن صرفا مجبور است که با 239 رکورد سر و کار داشته باشد.
پرس و جوی شاخص نشده، از طرف دیگر، مجبور است در بین 48،145 رکورد برود برای اینکه ببیند که آیا آنها مطابق با معیار هستند یا نه.
شاخصهای مختلف فیلد:
اگر شاخص یک جدول شامل چندین فیلد به هم متصل باشد، از این رو تاحدی بهینه سازی رخ می دهد اگر دستوری اجرا گردد.
به منظور به حساب آوردن یک فیلد که بخشی از شاخص می باشد، شما قبل از آن باید هر فیلد را به حساب بیاورید.
به عنوان مثال، بیایید بگوییم شاخص شامل سه فیلد است، شماره مشتری، نام خانوادگ و نا (CUSTOMER_NUMBER, LAST_NAME AND FIRST_NAME). اگر فرمان ور(WHERE clause) فقط شامل فیلد نام خانوادگی بود، برنامه راه انداز ODBC نمی توانست هیچگونه بهینه سازییی انجام دهد. اگر یک پرس و جو حتما باید روی فیلد نام خانوادگی انجام شود، فیلد شماره مشتری نیز لازم است به حساب آورده شود. بعلاوه، اگر پرس و جو فیلد نام را استفاده کرده است، برای اطمینان حاصل کردن از بهینه سازی مناسب، باید دو فیلد دیگر را نیز در بر بگیرد.
اما درمورد اضافه کردن شاخصها به فایل تک کلیدی یا چند کلیدی شده چه؟
همراه با یک فایل چند کلیدی، ممکن است چندین شاخص تعریف شده باشد. با این وجود، برای یک فایل تک کلیدی، فقط مجاز است یک شاخص داشته باشد. برطبق قاعدع ای که در بالا بطور خلاصه ذکر گردید، تمامی پرس و جوها اجرا میشوند برخلاف آن جدول بایستی برگردد به یکی از فیلدهایی که کلید اولیه بدان ارجاع می کند. اگر پرس و جویی اجرا میشود که آن قاعده را پیروی نمی کند، درنتیجه هیچگونه بهینه سازییی نمی تواند رخ دهد. دو روش ممکن برای این مسئله وجود دارد. اولی، در عوض شروع به استفاده از فایلهای چند کلیدی می باشد، چون آنها به یک دانه شاخص محدود نمی گردند. روش دوم، درگیر ایجاد فایل دیگری می گردد. این فایل جدید شاخصی خواهد داشت که با استفاده از فیلد شاخص نشده جدول و یکی از فیلدهای شاخص شده اش تعریف شده است. پرس و جوی جدید قادر است فرمانی را روی جدول قدیمی و جدول جدید اجرا نماید. پرس و جوی برگزیده (select query) به فیلد مورد نظر در جدول جدید برمی گردد، که جزئی از شاخصش می باشد.
چون آن همچنین مقدار یک فیلد شاخص شده ای را برمی گرداند، این اطلاعات برای یافتن رکوردهای مورد نظر در جدول اصلی توسط شاخص می توانند استفاده شوند.
مترجم : علی اکبر حاتمی
