نمایه سازی مانند فیلترها

اپراتور SQL مانند اغلب باعث رفتار عملکرد غیر منتظره ای می شود زیرا برخی از اصطلاحات جستجو از استفاده از شاخص کارآمد جلوگیری می کند. این بدان معناست که اصطلاحات جستجو وجود دارد که می توانند بسیار خوب فهرست شوند ، اما دیگران نمی توانند. این موقعیت شخصیت های کارت وحشی است که همه تفاوت ها را ایجاد می کند.

مثال زیر از ٪ Wild Wild در وسط اصطلاح جستجو استفاده می کند:

برای این مثال ، پرس و جو تغییر یافته است تا جایی که Last_name مانند "Win ٪ D" (بدون بالا) را بخوانید. به نظر می رسد DB2 LUW 10. 5 نمی تواند از پیش بینی های دسترسی مانند یک شاخص مبتنی بر عملکرد استفاده کند (در بهترین حالت یک اسکن کامل با شاخص انجام می دهد).

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

مانند فیلترها فقط می توانند از کاراکترها قبل از اولین کارت وحشی در هنگام عبور از درخت استفاده کنند. شخصیت های باقیمانده فقط پیش بینی های فیلتر هستند که دامنه شاخص اسکن شده را محدود نمی کنند. بنابراین یک عبارت مانند تک می تواند شامل دو نوع محمول باشد: (1) قسمت قبل از اولین کارت وحشی به عنوان یک محمول دسترسی.(2) شخصیت های دیگر به عنوان یک محمول فیلتر.

احتیاط

برای پایگاه داده PostgreSQL ، ممکن است لازم باشد یک کلاس اپراتور (به عنوان مثال ، varchar_patte_ops) را مشخص کنید تا از عبارات مانند به عنوان پیش بینی های دسترسی استفاده کنید. برای جزئیات بیشتر به "کلاس های اپراتور و خانواده های اپراتور" در مستندات PostgreSQL مراجعه کنید.

پیشوند قبل از اولین کارت وحشی انتخابی تر ، محدوده شاخص اسکن شده کوچکتر می شود. این به نوبه خود ، باعث می شود که شاخص سریعتر باشد. شکل 2. 4 این رابطه را با استفاده از سه عبارت متفاوت مانند نشان می دهد. هر سه ردیف یکسان را انتخاب می کنند ، اما محدوده شاخص اسکن شده - و بنابراین عملکرد - بسیار متفاوت است.

شکل 2. 4 مانند جستجوهای مختلف

عبارت اول دو شخصیت قبل از کارت وحشی دارد. آنها محدوده شاخص اسکن شده را به 18 ردیف محدود می کنند. فقط یکی از آنها با کل بیان مطابقت دارد - 17 مورد دیگر نیز بدست آمده اما دور ریخته شده اند. عبارت دوم دارای پیشوند طولانی تری است که محدوده شاخص اسکن شده را به دو ردیف محدود می کند. با این عبارت ، پایگاه داده فقط یک ردیف اضافی را می خواند که برای نتیجه مهم نیست. آخرین عبارت به هیچ وجه دارای محمول فیلتر نیست: پایگاه داده فقط ورودی را می خواند که مطابق با کل عبارت است.

مهم

فقط قسمت قبل از اولین کارت وحشی به عنوان محمول دسترسی عمل می کند.

شخصیت های باقیمانده محدوده شاخص اسکن شده را محدود نمی کنند-ورودی های تطبیقی فقط از نتیجه خارج نمی شوند.

مورد برعکس نیز ممکن است: عبارتی مشابه که با کارت وحشی شروع می شود. چنین عبارتی مشابه نمی تواند به عنوان یک محمول دسترسی باشد. در صورت عدم وجود شرایط دیگر که پیش بینی های دسترسی را ارائه دهد ، این بانک اطلاعاتی مجبور است کل جدول را اسکن کند.

از عبارات مشابه با کارتهای وحشی پیشرو (به عنوان مثال ، "اصطلاح ٪") خودداری کنید.

موقعیت شخصیت های کارت وحشی بر استفاده از شاخص تأثیر می گذارد - حداقل در تئوری. در واقعیت ، بهینه ساز هنگام تهیه اصطلاح جستجو از طریق پارامترهای Bind ، یک برنامه اجرای عمومی ایجاد می کند. در این حالت ، بهینه ساز باید حدس بزند که آیا اکثر اعدام ها دارای کارت وحشی پیشرو هستند یا خیر.

از طرف خودم

اکثر بانکهای اطلاعاتی فقط فرض می کنند که در هنگام بهینه سازی یک شرط مشابه با پارامتر Bind ، هیچ کارت وحشی پیشرو وجود ندارد ، اما اگر عبارت مانند برای جستجوی متن کامل استفاده شود ، این فرض اشتباه است. متأسفانه هیچ راهی مستقیم برای برچسب زدن یک شرط مشابه به عنوان جستجوی متن کامل وجود ندارد. جعبه "برچسب زدن متن کامل مانند عبارات" تلاشی را نشان می دهد که کار نمی کند. مشخص کردن اصطلاح جستجو بدون پارامتر Bind بارزترین راه حل است ، اما این باعث افزایش بهینه سازی سربار و آسیب پذیری تزریق SQL می شود. یک راه حل مؤثر اما هنوز هم ایمن و قابل حمل این است که عمداً شرایط مشابه را تحت الشعاع قرار دهید."ترکیب ستون ها" این را با جزئیات توضیح می دهد.

برچسب زدن متن کامل مانند عبارات

هنگام استفاده از اپراتور مانند برای جستجوی متن کامل ، می توانیم کارتهای وحشی را از اصطلاح جستجو جدا کنیم:

برای پایگاه داده PostgreSQL ، مشکل متفاوت است زیرا PostgreSQL فرض می کند هنگام استفاده از پارامترهای اتصال برای یک عبارت مانند ، یک کارت وحشی پیشرو وجود دارد. PostgreSQL فقط در این مورد از شاخص استفاده نمی کند. تنها راه برای دستیابی به یک فهرست برای یک عبارت مشابه ، این است که اصطلاح جستجوی واقعی برای بهینه ساز قابل مشاهده باشد. اگر از یک پارامتر Bind استفاده نمی کنید اما اصطلاح جستجو را مستقیماً در بیانیه SQL قرار می دهید ، باید اقدامات احتیاطی دیگری را در برابر حملات تزریق SQL انجام دهید!

حتی اگر بانک اطلاعاتی برنامه اجرای یک کارت وحشی پیشرو را بهینه کند ، هنوز هم می تواند عملکرد کافی را ارائه دهد. شما می توانید از بخش دیگری از بند WHERE برای دسترسی به داده ها به طور کارآمد در این مورد استفاده کنید - همچنین به "پیش بینی های فیلتر شاخص استفاده شده عمدی" مراجعه کنید. اگر مسیر دسترسی دیگری وجود نداشته باشد ، ممکن است از یکی از راه حل های اختصاصی فهرست کامل متن زیر استفاده کنید.

DB2 از کلمه کلیدی موجود پشتیبانی می کند. به "آموزش جستجوی متن DB2" در IBM DeveloperWorks مراجعه کنید.

MySQL مسابقه و در برابر کلمات کلیدی را برای جستجوی متن کامل ارائه می دهد. با شروع MySQL 5. 6 ، می توانید شاخص های متن کامل را برای جداول IoDB نیز ایجاد کنید-پیش از این ، این فقط با جداول MyISAM امکان پذیر بود."توابع جستجوی متن کامل" را در مستندات MySQL مشاهده کنید.

پایگاه داده اوراکل کلمه کلیدی را ارائه می دهد. به "راهنمای توسعه برنامه کاربردی متن اوراکل" مراجعه کنید.

PostgreSQL برای اجرای جستجوهای متن کامل به اپراتور ارائه می دهد. به "جستجوی متن کامل" در مستندات PostgreSQL مراجعه کنید.

گزینه دیگر استفاده از پسوند WildSpeed برای بهینه سازی مستقیم عبارات است. پسوند متن را در تمام چرخش های ممکن ذخیره می کند تا هر کاراکتر در ابتدا یک بار باشد. این بدان معناست که متن ایندکس شده نه تنها یک بار ذخیره می شود بلکه در عوض هر چند بار شخصیت هایی در رشته وجود دارد - بنابراین به فضای زیادی احتیاج دارد.

SQL Server شامل کلمه کلیدی حاوی است. به "جستجوی متن کامل" در مستندات SQL Server مراجعه کنید.

به آن فکر کنید

چگونه می توانید یک جستجوی مشابه را که فقط در ابتدای اصطلاح جستجو ("٪ term") وجود دارد ، فهرست بندی کنید؟

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

مارکوس وینند سفیر SQL Renaissance است. او در مأموریت برای معرفی توسعه دهندگان با تکامل SQL در قرن بیست و یکم است. مارکوس را می توان به عنوان مربی ، سخنران و مشاور از طریق Winand. at استخدام کرد.

کتاب او را بخرید

جوهر تنظیم SQL در 200 صفحه

شومیز همچنین در Amazon.com موجود است.

استخدام مارکوس

مارکوس آموزش و مشاوره SQL را برای توسعه دهندگان که در شرکت هایی با هر اندازه کار می کنند ارائه می دهد. بیشتر بدانید "