گام نهایی این بود که مجب شویم فیلد برتر برای برنامه راه انداز ODBC خیلی کمتر جذاب باشد. این کار انجام گردید با پیچیده تر کردن مقایسه-آن تغییر داده شد از مساوی است با به شبیه است. بخاطر همین، برای بهینه سازی فیلد CALL_DATEانتخاب گردید. همانطور که در بالا ذکر شد، این می تواند بطور جدی مقدار کاری را که برنامه راه انداز ODBC باید انجام دهد کاهش دهد. نتایج زمان بندی در اینجا بیان گردیده اند:
پرس و جو براساس برتری بهینه سازی گردیده است 3.25 ثانیه
پرس و جو براساس CALL_DATEبهینه سازی گردیده است 0.05 ثانیه
زمان بندیها نشان می دهد که تنظیم پرس و جو از یک افزایش 6500% در سرعت ناشی میشود-کاملا یک پیشرفت چشمگیر! درواقع، سود عملکرد در این پرس و جو بهتر بود از پرس و جویی که فرمان ور شاخص شده و شاخص نشده را با هم مقایسه می کند. این نکته مهم است زیرا آن اشاره می کند که هرچند ممکن است یک پرس و جو بدون فیلدهای شاخص شده رجوع کند و بهینه سازی نماید، آن باز هم ممکن است به همان خوبی که می توانست عمل نکند. اینگونه تنظیم سازی می تواند تاثیر ژرفی روی سرعت پرس و جو بگذارد، اما تنها مقدار زیادی دانش درمورد جدول و داده هایی که جستجو میشوند نیاز دارد. مثال قبل به زیبایی آن را نشان داد-سود کار صرفا فهمیده میشد زیرا برنامه راه اندازODBC مجبور گردید روی فیلد خاصی بهینه سازی نماید. این بدین معنا است که کاربر مجبور بود کار اضافه ای را انجام دهد تا برنامه راه انداز ODBC را ملزم نماید که بدون یک فیلد خاص بهینه سازی کند. به علاوه، کاربر از پیش می دانست که فیلد CALL_DATE گزینه خیلی بهتری می باشد، چونکه آن دو واقع مقدار داده هایی را که برنامه راه انداز ODBC مجبور است بررسی نماید را محدود می کند. بدون داشتن آگاهی خوب از محتویات جدول، این نوع بهینه سازی هرگز اتفاق نمی افتد.
مرور:
بطور خلاصه، رجوع کردن به فیلدهای شاخص شده در پرس و جوهایتان موثرترین روش برای بدست آوردن اطمینان از عملکرد سریع می باشد. اگر مکررا پرس و جوهایی را اجرا نمایید که نمی توانند بهینه سازی گردند چون آنها به فیلدهای شاخص شده رجوع نمی کنند، ممکن است بازسازی جدول با اضافه کردن شاخصها برای اطمینان از کارائی سریعتر ارزشمند باشد. توجه کنید که این معمولا یک پروسه دو مرحله ای است. اولین مرحله ایجاد کردن شاخصی در فرهنگ داده ها می باشد، و مرحله بعدی کلید دار کردن مجدد فایل داده های فیزیکی BBX است چون آن فیلد جدیدی را بعنوان یک کلید تعریف کرده است. هنگامی که این عمل توسط PRO/5 انجام گردید، این درگیر ایجاد فایل جدیدی با تعریف کلید جدیدی در عبارت چند کلیدی که دارای شاخصی برای فیلد مورد نظر است می گردد. یک مرتبه فایل جدید ایجاد شده است، یک برنامه کوتاهی باید اجرا شود-برنامه ای که تمامی رکوردها را از فایل قدیمی می خواند و در فایل جدید می نویسد. با وجود برنامه راه انداز ODBC BASIS، به هر حال، تکمیل این عملیات توسط دستور زبان پرس و جوی ساختاری CREATE INDEX امکان پذیر است. زمانی که این دستور SQL اجرا میشود، برنامه راه انداز ODBC فرهنگ داده ها را برای در بر داشتن شاخص جدید تغییر نخواهد داد، اما، آن همچنین دوباره آن فایل را کلید دار می نماید.
محدود کردن مقدار داده هایی که برگردانده میشوند
یک روشی که اغلب چشم پوشی شده درمورد بهینه کردن زمانهای پرس و جو تنها برگرداندن داده هایی می باشد که واقعا مورد نیازند. به دقت بررسی کردن تمام جدول یا بطور ساده ای انجام دادن پرس و جویی از یک جدول امری بسیار عادی می باشد.
درصورتی که ممکن است بعضی اوقات مشاهده هر فیلد هر رکورد ضروری باشد، در بسیاری موارد، این کار انجام میشود تنها بخاطر اینکه آسان تر است. بدون توجه به اینکه آیا همه داده ها استفاده میشوند یا نه. بنابراین، قبل از انجام دادن یک پرس و جو، عاقلانه است که تعیین کنید چه فیلدها و رکوردهایی واقعا مورد نیازند، و باعث شوید که پرس و جو تنها داده های ضروری را برگرداند. یعنی، فرمان ور باید ساخته شود برای غربال کردن تا حد امکان به اندازه غربالی که روی داده های مورد نیاز انجام میشود. علاوه براین، اگر تنها یک بخش از فیلدها لازم هستند، از نوع مرسوم پرس و جو (select query) دوری کنید. درعوض، باعث شوید که بازگشت فقط به فیلدهای ضروری باشد که از داده های بسیار کمتری که در حال پردازش هستند و پرس و جوهای سریعتر ناشی میشوند. این مخصوصا زمانی مهم است که جدول تعداد زیادی ستون دارد، یا ستونهایی که بعنوان فیلدهای کاراکتری بزرگ تعریف شده اند. اگر بعضی از این ستونها برای جدول نتیجه ضروری نیستند، حذف کردن آنها از پرس و جو به داده های خیلی کمتری که منتقل میشوند- که در پرس و جوهای سریعتری تفسیر می گردند منتج میشود. مثالی در ذیل این موضوع را نشان می دهد:
هدف این پرس و جو فهمیدن تعدادهای فرمان بازگشت است که توسط یک تکنسین ویژه انجام شده است می باشد. این پرس و جو می توانست به دو روش انجام گردد:
Select * from hist_log where TECH = ‘abc’”
Select id from hist_log where TECH = ‘aabc’”
اولین روش هر فیلد را برای هر ردیفی که برگردانده شده است می خواهد. هدف پرس و جو صرفا دریافتن این بود که کدام فرمانها توسط تکنسین بکار برده شدند، با این وجود، درنتیجه تنها فیلد ID لازم است برگردانده شود. پرس و جوی دوم از آن حقیقت استفاده می کند. زمانهای نتیجه گیری در اینجا ذکر گردیده اند:
انتخاب کردن همه فیلدها: 8.09 ثانیه
انتخاب کردن فیلد ID : 1.28 ثانیه
در این مورد، بازیافتن تنها داده های ضروری باعث گردیده که پرس و جو 632% سریعتر اجرا گردد!