SELECT from CALL_LOG where ID>’0000022000’ TIME<9)
این تمامی رکوردها را از جدول (CALL_LOG) که تا قبل از ساعت نه صبح فرمانی بدان اضافه می شده است و کد تماس بزرگتر از ‘0000022000’ می باشد زیرا شاخص اولیه براساس کد تماس است، لذا برنامه راه انداز ODBC می تواند سریعا رکوردها را بازیابی کند. در اینجا گلچینی از فایل ثبت وقایع (log file)می باشد:
استراتژی بهینه سازی:
(file 1) = f:/odbc/LOCAL_CALL_Hist/data/call_log
Order_knum=-1
(Selected) Predicate: 1 constraints
*!: (file 1)(knum= 0, kseg= 1) ID(bracket head)
گزاره : قیدها
predicate: 1 constraints
*: (file 1)(knum= -1, kseg= -1) ID(no bracketing)
توجه کنید که برای نشان دادن استراتژی بهینه سازی بکار رفته، فایل ثبت وقایع log file) حاوی چندین قطعه اطلاعاتی می باشد. اول از همه، برای اینکه نشان دهد که برای ادامه بهینه سازی قادر است شاخصی را انتخاب نماید. ثانیا، برای اتمام بهینه سازی دو گزینه ممکن را لیست می کند، یکی بجای فیلد کد)شناسه( و یکی بجای فیلد زمان. ابتدا فیلد کد(شناسه) لیست می گردد و the knum=0, kseg= 1 که نشان می دهد که آن کلید اولیه است. خط دوم که لیست شده است درمورد فیلد زمان می باشد. هرچند که knum و kseg آن فیلد منفی یک هستند، این نشان می دهد که هیچگونه شاخصی که برپایه فیلد زمان وجود ندارد.
در مثال بالا، برنامه راه انداز ODBC برای ادامه بهینه سازی از شاخص اصلی که برپایه فیلد کد تماس می باشد استفاده کرده است. این عمل توسط ‘!’ قبل از خطش نشان داده میشود.
پرس و جوی شاخص نشده:
SELECT * from CALL_LOG where TIME<9
این انتخاب می کند تمامی رکوردها)وقایع( را از جدول کال لاگ (CALL_LOG) که قبل از ساعت نه صبح در آن پدید آمده است. هرچند هیچ شاخصی براساس فیلد زمان وجود ندارد، برنامه راه اندازODBC نمی تواند پرس و جو را بهینه سازی نماید. در اینجا گلچینی از فایل ثبت وقایع وجود دارد:
استراتژی بهینه سازی:
(file 1)= f:/odbc/LOCAL_CALL_Hist/data/call_log
Order_knum= -1
Predicate: 1 constraints
*:( file 1)(knum= -1, kseg= -1) ID(no bracketing)
توجه کنید که آن یک (SELECTED) یا ‘!’ برای نشان دادن شاخص انتخاب شده ندارد.
یک مثال پیچیده تر:
SELECT CALL_TRN.TECH CALL_TRN.TRN_DATE from CALL_LOG,
CALL_TRN where CALL_LoG ID between ‘0000020000’ and ‘0000022000’
CALL_LOG.TIME<9and CALL_LOG.TECH= ‘ABC’ and CALL_LOG.ID= CALL_TRN.ID order by CALL_TRN.TECH
این پرس و جو از نمونه های قبلی بسیار پیچیده تر است هرچند که آن اتصالی را بین جداول CALL_LOG و CALL_TRNایجاد می کند، دو بار به فیلد CALL_LOG.ID برمی گردد و دستوری را اجرا می نماید. در اینجا گلچین فایل ثبت وقایع وجود دارد:
استراتژی بهینه سازی:
(file 1)= f:/odbc/LOCAL_CALL_Hist/dat/call_log
Order_knum= -1
(SELECTED) Predicate: 1 constraints
*(file 1)(knum= -1, kseg= -1)ID(bracket head)
Predicate= 1 constraints
*file 1)(knum= 0, kseg= 1)ID(bracket tail)
Predicate: 1 constraints
*file 1)(knum= -1, kseg= -1)ID(no bracketing)
Predicate: 1 constraints
*file 1)(knum= 0, kseg= 1)ID(partial key: knum=0)
(file 2)= f:/odbc/LOCAL_CALL_Hist/data/call_log
Order_knum=-11
(SELECTED) Predicate: 2constraints
*: (file 1)(knum=0, kseg= 1)ID(primary key)
*: (file 2)(knum= 0, kseg= 1)ID(partial key: knum=0)
فایل ثبت وقایع نشان می دهد که برنامه راه انداز ODBC بیشتر با آن پرس و جو کار می کرد برای اینکه بهترین فیلد را برای ادامه بهینه سازی معین کند. آن تقریبا هر فیلدی را که در پرس و جو ذکر شده بررسی کرده است. دو مدخل اولی برای اولین فایل به فیلد کد)شناسه( مربوط می باشد. برای این فیلد دو مدخل وجود دارد، کروشه بازو کروشه بسته. زیرا این فیلد دو مرتبه برای مقایسه استفاده گردیده است. علاوه بر این، توجه کنید به اینکه تمام مدخلها پس از بخش knum و kseg شان برای نشان دادن کلید اولیه، آن شاخص اصلی را لیست می کنند. سومین مدخل نمی توانست استفاده شود چون همانطور که در بالا ذکر گردید، شاخصی مربوط به آن فیلد وجود ندارد. چهارمین مدخل بیان می کند که می توانست انجام یک بررسی کلیدی مختصری را برپایه کلید اولیه انتخاب نماید. درعوض فایل دوم دو مدخل را لیست می نماید. اولی کلید اولیه است برای اولین جدول. دومین مدخل،)که انتخاب شد( نشان می دهد که قادر بوده یک بررسی کلیدی مختصر را بدون کلید اولیه انجام دهد. توجه کنید که این یک کمی با جدول اولی تفاوت دارد. برای جدول اول، آن مستقیما بدون شناسه (ID) کلیدی شده است، اما می گوید که آن تنها می تواند یک بررسی کلیدی مختصری را بدون شناسه (ID) برای جدول دوم انجام دهد. دلیل این کار این است که کلید اولیه بدون فیلدهای گوناگونی برای جدول دوم ایجاد میشود. درنتیجه، چون که شاخص اصلی (CALL_TRN) شامل فیلد شناسه ای (ID) بود که با دو فیلد دیگر همراه بود، برنامه راه انداز ODBC نمی توانست مستقما بدون کلید اولیه کلید دار نماید. در عوض، آن می توانست یک بررسی کلیدی)مهم( مختصری را انجام دهد زیرا آن پرس و جو به بخش اول آن کلید اولیه برمی گشت.
مترجم : علی اکبر حاتمی
