ساختن پرس و جو به طور صحیح:

هرچند ممکن است یک پرس و جو برای استفاده از فیلدهای شاخص شده ساخته شود، دو پارامتر دیگر وجود دارند که نشان می دهند یک پرس و جو چقدر سریع می تواند اجرا گردد. آن دو پارامتر ترتیب فیلدها در فرمان (WHERE) می باشند و چقدر فرمان مقایسه ای ساده است. این نکته با مثالی بهتر نشان داده میشود.

هدف پرس و جو پیدا کردن تمامی اطلاعات مربوط به هر فرمان در محدوده داده خاص داده ها می باشد جایی که آن فرمان از سطح اولویت بخصوصی برخوردار است. اولین پرس و جو اینجا ذکر گردیده :

Select * from hist_log where PRIORITY= ‘4’ and CALL_DATE between {d ‘1997-07-07’} and {‘1997-07-07’}

استراتژی بهینه سازی:

(file 1)= f:/odbc/Local_Call_Hist/data/Hist_Log
Order_knum= -1
(Selected) Predicate: 1 constraints
*: (file 1) (knum= 7, kseg= 1) ID(alternate key: knum= 7)
Predicate: 1 constraints
*: (file 1) (knum= 2, kseg= 1) ID( bracket head)
Predicate: 1 constraints
*: (file 1) (knum= 2, kseg= 1) ID(bracket tail)

از فایل ثبت وقایع، ما می توانیم نتیجه بگیریم که آن فایل فیلد برتر را برای بهینه سازی برگزیده. هم فیلد برتر (PRIORITY field) و هم فیلد (CALL_DATE) برای این فایل شاخصهای فرعی هستند. برنامه راه انداز ODBC به دو دلیل فیلد برتر را برگزید

آن فیلد ابتدا در فرمان ور (WHERE clause) ذکر شده بود

مقایسه کردن برای آن فیلد (PRIORITY field) خیلی ساده تر بود تا برای فیلد CALL_DATE

دلیل دومی مخصوصا مهم است. زیرا، فیلد CALL_DATE برای یک مقایسه پیچیده تری استفاده شده، اما فیلد برتر PRIORITY field برای بهینه سازی انتخاب گردیده است. این موضوع توسط پرس و جوی زیر روشن تر می گردد:

Select * from Hist_Log where CALL_DATE between {d ‘1997-07-07’} and {d ‘1997-07-07’} and PRIORITY= ‘4’

استراتژی بهینه سازی :

(file 1)= f:/odbc/Local_Call_Hist/data/Hist_log
Order_knum= -1
Predicate: 1 constraints
*: (file 1) (knum= 2, kseg= 1) ID(bracket head)
Predicate: 1 constraints
(Selected) predicate: 1 constraints
*: (file 1) (knum= 7, kseg= 1) ID(alternate key: knum=7)

در این مورد، فیلد برتر آخر در فرمان ور ذکر شده، اما باز هم پیش از فیلد CALL_DATE انتخاب شده چون تطبیق کردن برای آن خیلی ساده تر بود.

اکنون، این همه چه ربطی به بهینه سازی دارد؟ پاسخ این است که هرچند این دو شاخص یکسان به نظر می رسند )زیرا هد دو آنها شاخصهای فرعی هستند(، لذا، با بهینه کردن بدون فیلد CALL_DATE ما می توانیم عملکرد خیلی بهتری به دست آوریم. دلیل ساده است، در فایل داده ها هزاران رکورد با برتری ‘4’ وجود دارد، اما تنها یکی دو جین در محدوده تاریخی تعیین شده. به عبارت دیگر، اگر بهینه سازی براساس فیلد برتر باشد، برنامه راه انداز ODBC بررسی و تطبیق هزاران رکورد را با تاریخ تعیین شده خاتمه می دهد. با این وجود، اگر بهینه سازی براساس فیلد CALL_DATE باشد، برنامه راه انداز ODBC حدود سی رکورد را بررسی کرده و با آن سطح اولویت تعیین شده مقایسه می کند. به منظور لحاظ کردن این موضوع، این پرس و جو برای بار سوم امتحان میشود:

Select * from Hist_log where CALL_DATE between {d ‘1997-07-07’} and {d ‘1997-07-07’} and PRIORITY like ‘4%’

استراتژی بهینه سازی :

(file 1)= f:/odbc/Local_call_Hist/data/Hist_log
Order_knum= -1
(Selected) Predicate: 1 constraints
*: (file 1) (knum= 2, kseg= 1) ID(bracket head)
Predicate: 1 constraints
*: (file 1) (knum= 2, kseg= 1) ID(bracket tail)
Predicate: 1 constraints
*: (file 1) (knum= -1, kseg= -1) ID(no braketing)
Predicate: 1 constraints
*: (file 1) (knum= 7, kseg= 1) ID(bracket head)
Predicate: 1 constraints
*: (file 1) (knum= 7, kseg= 1) ID (braket tail)

این بار، پرس و جو قادر بود که برنامه راه انداز ODBC را وادار کند که فیلد CALL_DATE را برای بهینه سازی انتخاب نماید. برای انجام این کار، فیلد CALL_DATE ابتدا در عبارت ور فهرست شد. از این رو، همانگونه که در پرس و جوی دوم نشان داده شد، آن کاملا کافی نبود.

مترجم : علی اکبر حاتمی