یادگیری سی شارپ از مفاهیم پایه تا پروژه محور: شی‌گرایی، کار با SQL و LINQ، ORMها (Entity Framework)، ساخت پروژه مدیریت رستوران با گزارشات حرفه‌ای و امکانات کامل!
مشاهده بیشتر
تو این دوره SQL Server رو از صفر تا پیشرفته یاد می‌گیری! از تراکنش‌ها و طراحی دیتابیس تا Query نویسی حرفه‌ای و پروژه‌های واقعی مثل مدیریت فروش و سیستم مالی. همه چی رو با مثال و تمرین یاد می‌گیری و یه متخصص دیتابیس می‌شی!
مشاهده بیشترمشخصات مقاله
-
1481
-
0.0
-
4145
-
0
-
0
اجتناب از استفاده از کاراکترهای Wildcraft برای شروع معیارهای جستجو
اجتناب از استفاده از کاراکترهای Wildcraft برای شروع معیارهای جستجو
هنگامی که از اپراتور LIKE استفاده می کنید و اولین کاراکتر در رشته ی جستجو یک کاراکتر wildcraft باشد، % یا SQL Optimizer مجبور خواهند بود که اسکن یک جدول یا ایندکس را در هنگام اجرای query انجام دهند.
توضیحات
قبل از اینکه وارد جزئیات مربوط به توضیح خود شویم، اجازه بدهید یک ایندکس روی ستونی ایجاد کنیم که قصد داریم از آن در عبارت WHERE مربوط به query خود استفاده کنیم. در اینجا کدی را مشاهده می کنید که برای ایجاد ایندکس مورد نظر روی جدول Child استفاده می شود.
1 2 3 4 5 6 | CREATE NONCLUSTERED INDEX idxChild_VarcharDataColumnON [dbo].[Child] ([VarcharDataColumn]) -- cleanup statements--DROP INDEX Child.idxChild_VarcharDataColumn<button></button> |
بنابراین چرا باید اسکن جدول/ایندکس انجام شود؟ از آنجایی که همه ی ایندکس های SQL Server در یک B-Tree structure ذخیره شده اند، وقتی معیارهای جستجوی خود را با یک کاراکتر Wildcraft آغاز می کنیم، optimizer قادر به استفاده از ایندکس برای اجرای جستجو برای یافتن سریع داده نمی باشد. بنابراین اگر همه ی ستون های لازم برای query بخشی از ایندکس باشند، یا اسکن از یک جدول را اجرا می کند و یا اسکن از یک ایندکس را. اکنون متوجه شدم که برخی موارد وجود دارند که در آنها براساس نیازهایتان این امر ممکن نیست، اما مثال زیر نشان می دهد که چرا باید هرجا ممکن است از انجام چنین کاری اجتناب شود. اجازه بدهید یک query ساده بنویسیم که یک جستجو روی ستونی که در بالا ایندکس کردیم، انجام می دهد. در اینجا کد وضعیت SQL را مشاهده می کنید.
1 2 3 | SELECT * FROM [dbo].[Child] WHERE VarcharDataColumn LIKE '%EST5804%'<button></button> |
با نگاه کردن به explain plan برای این query متوجه می شویم که ایندکس روی VarcharDataColumn که ایجاد کرده ایم، نادیده گرفته شده و یک clustered index(لزوما اسکن از جدول) باید اجرا شود.
اکنون اجازه بدهید رشته ی بدهید رشته ی جستجو را در این query تغییر دهیم تا wildcard را حذف کنیم، بنابراین رشته ای که در حال جسججوی آن هستید با یک کاراکتر معتبر آغاز می شود. در اینجا وضعیت آپدیت شده ی SQL را مشاهده می کنید. نکته: من معیار جستجو را طوری انتخاب کردم که هر دو query یک نتیجه را ارائه بدهند و نتایج به وسیله ی یک query تغییر نمی یابند و یک مجموعه ی نتیجه ی بزرگتر را گزارش می دهد.
1 2 3 | SELECT * FROM [dbo].[Child] WHERE VarcharDataColumn LIKE 'TEST5804%<button></button> |
با نگاه کردن به explain plan برای این query متوجه می شویم که optimizer در حال استفاده از ایندکسی می باشد که ایجاد کردیم و یک جستجو به جای یک اسکن انجام می دهد:
گرچه فقط با مقایسه ی explain plans باید قادر به تشخیص اجرای بهتر query دوم باشیم، اجازه بدهید تایید کنیم که در واقع این query از منابع کمتری استفاده می کند و اجرای آن از query آغازین سریعتر می باشد. در زیر مشاهده می کنیم که با حذف کاراکتر wildcard از ابتدای query، در واقع یک پیشرفت خیلی بزرگ مشاهده می کنیم: