هفت نکته برای افزایش عملکرد پرس و جو SQL Server
7 نکته برای افزایش عملکرد پرس و جو SQL Server
هنگام کاهش زمان پاسخگویی برای برنامه های تحت وب که از پایگاه داده SQL Server استفاده شده ، توسعه دهندگان به بهینه سازی پرس و جو SQL توجه زیادی ندارند. در اینجا چند نکته در مورد بهینه سازی پرس و جو SQL ارائه شده است که
می تواند سرعت اجرای پرس و جوهای نوشته شده به زبان SQL Server را بسیار افزایش دهد.
هنگامی که بهینه سازی عملکرد را برای کاهش زمان پاسخگویی برای برنامه های تحت وب و یا تحت شبکه را مشاهده می کنم ، تغییرات اغلب در لایه برنامه یا با بررسی وجود فهرست در ستون جدول بانک اطلاعات انجام می شود و توجه بسیار کمتری به تنظیم و
مرتب سازی پرس و جو SQL شده است. حتی معماران و توسعه دهندگان متخصص تمایل دارند فراموش کنند که درک چگونگی عملکرد پایگاه داده در داخل و نوشتن نمایش داده های بهتر SQL برای دستیابی به عملکرد بهتر بسیار مهم است. در اینجا هفت نکته
ساده وجود دارد که عملکرد و کارآیی و performance پرس و جوهای SQL شما را افزایش می دهد.
1. مالک owner / نام طرحواره Schema
همیشه نام اشیاء (به عنوان مثال جدول ، نام رویه ذخیره شده و غیره) را با Owner/Schema Name خود تنظیم کنید.
دلیل: اگر Owner/Schema Name ارائه نشده باشد ، موتور SQL Server سعی می کند تا زمانی که شیء آن را پیدا نکند ، آن را در تمامی Schema Name جستجو کرده و آنرا پیدا کند. اگر Owner/Schema
Name ارائه شده باشد ، موتور SQL سرور جدول را جستجو نمی کند.
2. * اپراتور علامت star همکاه با select
در کوئری ها SELECT از اپراتور * استفاده نکنید. در عوض ، از نام ستون ها استفاده کنید.
دلیل: SQL Server اسامی همه نامهای ستون را اسکن می کند و * را با تمام نام های ستون جدول (ها) در جمله SQL SELECT جایگزین می کند. ارائه نام ستون ها از این جستجو و جایگزینی جلوگیری می کند و باعث افزایش عملکرد می شود.
3. ستون های دارای مقدار Null
هنگام مقایسه با ستون های دارای NULL ، از NOT IN استفاده نکنید. در عوض از EXISTS استفاده کنید.
دلیل: هنگامی که از IN در پرس و جو استفاده می شود (حتی اگر query سطرهایی را با مقادیر تهی برنمی گرداند) ، SQL Server هر نتیجه را بررسی می کند تا ببیند Null است یا خیر. با استفاده از NOT EXISTS ، مقایسه بر روی Null انجام نمی شود.
مقادیر NULL معمولا در پرس و جوها خطرناک و درد سر ساز هستند و اگر کاربر تجربه برخورد با این مقادر را نداشته باشد به مشکل بر خواهد خورد.
4- متغیرهای از نوع جدول Table و Join ها
از متغیرهای جدول در اتصالات یا Join ها استفاده نکنید. در عوض از جداول موقت ، CTE (عبارات جدول مشترک) یا جداول مشتق شده derived Tables در ارتباط بین جدولهای پایگاه داده استفاده کنید.
دلیل: گرچه متغیرهای جدول در بسیاری از شرایط بسیار سریع و کارآمد هستند ، اما موتور SQL Server آن را به صورت یک ردیف واحد می بیند. به همین دلیل ، آنها هنگام استفاده از Join ها به طرز وحشتناکی بد عمل می کنند. جدولهای CTE و جداول مشتق شده در مقایسه با متغیرهای جدول عملکرد بسیار بهتر با اتصالات بین جدولی یا Join ها دارند.
5. اسامی رویه ذخیره شده
نام روش ذخیره شده خود را با sp_ شروع نکنید.
دلیل: هنگامی که روش ذخیره شده sp_ یا SP_ نامگذاری شده باشد ، SQL Server همیشه در پایگاه داده سیستمی یا master جستجو و کار می کند ، حتی اگر نام Owner و Schema ارائه شده باشد. نام بدونSP_ به از این
بررسی غیر ضروری در پایگاه داده سیستمی Master در SQL Server جلوگیری می کند.
6. از SET NOCOUNT ON استفاده کنید
با عملیات DML از SET NOCOUNT ON استفاده کنید.
دلیل: هنگام انجام عملیات DML (یعنی INSERT ، DELETE ، SELECT و UPDATE) ، SQL Server همیشه تعداد ردیف های مورد اثر واقع شده را برمی گرداند. در پرس و جوهای پیچیده و دارای تعداد زیادی پیوست ، این مسئله به یک مشکل بزرگ تبدیل می شود. استفاده از SET NOCOUNT ON باعث بهبود کارایی خواهد شد زیرا تعداد ردیف های تحت تأثیر را نمی شمارد و پس از اتمام پرس و جو Message برنمیگرداند. برخی از گزارش سازها به این پیام برگشتی حساس هستند و ممکن است که از سوی سیستم نرم افزاری با مشکل عدم اجرای برنامه موجه شوید. در صورتی که پرس و جو به درستی اجرا می شود ولی برنامه به علت همان خروجی یک خطی کوتا از کار می افتد.
7. از استفاده از GROUP BY ، ORDER BY و DISTINCT خودداری کنید
تا حد امکان از استفاده از GROUP BY ، ORDER BY و DISTINCT خودداری کنید
دلیل: هنگام استفاده از GROUP BY ، ORDER BY یا DISTINCT ، موتور SQL Server یک جدول کاری ایجاد می کند و داده ها را در جدول کار قرار می دهد. پس از آن ، این داده ها را مطابق درخواست پرس و جو در جدول کار سازماندهی می کند و سپس نتیجه نهایی را برمی گرداند. و این مساله خود باعث افزایش هزینه های بالاسری SQL Server خواهد شد. بنابراین فقط در مواقع ضروری از سؤال خود از GROUP BY ، ORDER BY یا DISTINCT استفاده کنید.
نتیجه
برنامه های پیچیده و بزرگ معمولاً نیازهای پیچیده ای را ایجاد می کنند. این امر ما را به نوشتن پرس و جوهای پیچیده SQL سوق می دهد. این تغییرات ساده در نمایش رکوردهای SQL Server باعث تغییر بسیار زیادی در زمان پاسخ خواهد شد.
با تشکر از شما برای خواندن مقاله من. امیدوارم مفید واقع شود. لطفا یک نظر ما را میهمان نمایید . . .