بررسی پیشرفته اپراتورها در نقشه اجرا Execution Plan برای بهبود عملکرد و بهینهسازی کوئریها در SQL Server بسیار مهم است. این اپراتورها نشان دهنده چگونگی اجرای کوئری و انجام عملیاتهای مختلف روی دادهها در موتور پایگاه داده میباشند. در زیر، چندین اپراتور پیشرفته رایج در نقشه اجرا ذکر شده است:
- Nested Loops :
– این اپراتور متداولترین اپراتور است و برای اجرای عملیات Join استفاده میشود. در این حالت، برای هر رکورد از یک جدول، به جستجو در جدول دیگر پرداخته میشود.
این نوع Join یکی از سادهترین و پراستفادهترین روشها برای انجام Join در SQL Server است. این نوع Join معمولاً برای اتصال دو جدول کوچک به یکدیگر استفاده میشود.
عملکرد این Join به این صورت است که برای هر رکورد از یک جدول (جدول خارجی)، به جستجو در رکوردهای دیگری از جدول دیگر (جدول داخلی) میپردازد.
در نقشه اجرا، Nested Loop Join به عنوان Nested Loops یا Nested Loops (Inner Join) نمایش داده میشود.
- Merge Join :
– این اپراتور برای ادغام دو مجموعه مرتب داده مورد استفاده قرار میگیرد. برخلاف Nested Loops، این اپراتور فقط برای ادغام دو جدول مرتب استفاده میشود.
در Merge Join، دو جدول ورودی باید به ترتیب مرتب شوند، سپس از یک الگوریتم ادغام برای ادغام دو جدول استفاده میشود.
این نوع Join برای اتصال دو جدول بزرگ و مرتب استفاده میشود، ولی باید توجه داشت که این روش فقط برای انواع خاصی از Join قابل استفاده است.
در نقشه اجرا، Merge Join به عنوان Merge Join یا Sort-Merge Join نمایش داده میشود.
- Hash Match :
– در این اپراتور، یک جدول به یک تابع هش تبدیل میشود و سپس با استفاده از تابع هش، مقادیر متناظر در جدول دیگر پیدا میشوند. این اپراتور برای عملیات Join مفید است، به خصوص زمانی که دادهها بر روی حافظه اصلی بارگذاری میشوند.
در Hash Join، دو جدول ورودی به یک تابع هش تبدیل میشوند و سپس با استفاده از تابع هش، مقادیر متناظر در دو جدول پیدا میشوند.
این نوع Join برای اتصال دو جدول بزرگ و نامرتب استفاده میشود و میتواند عملکرد بهتری نسبت به سایر روشهای Join در برخی شرایط فراهم کند، به ویژه زمانی که دادهها در حافظه اصلی قرار دارند.
در نقشه اجرا، Hash Join به عنوان Hash Match نمایش داده میشود.
- Index Seek :
– این اپراتور برای جستجوی سریع بر اساس ایندکسهای موجود استفاده میشود. با استفاده از این اپراتور، موتور پایگاه داده به سرعت به رکوردهای مورد نظر دسترسی پیدا میکند.
- Index Scan :
– این اپراتور برای پویش کامل یک ایندکس استفاده میشود. اگر جستجوی دقیق Seek ممکن نباشد یا این که مقادیر متنوعی برای جستجو دارید، این اپراتور ممکن است استفاده شود که معمولاً کندتر از Index Seek است.
- Clustered Index Scan :
– این اپراتور برای پویش کامل یک ایندکس خوشهای Clustered Index استفاده میشود. این اپراتور معمولاً زمانبرتر از Index Scan است.
- Table Scan :
– این اپراتور برای پویش کامل یک جدول بدون استفاده از ایندکسها استفاده میشود. این اپراتور معمولاً زمانبر و کندترین روش دسترسی به دادهها است.
- Sort :
– این اپراتور برای مرتبسازی نتایج یک کوئری استفاده میشود. اگر نتایج بر اساس یک فیلد خاص مرتب شود، این اپراتور ممکن است استفاده شود.
بررسی این اپراتورها در نقشه اجرا از اهمیت بالایی برخوردار است، زیرا میتواند نقاط ضعف و نقاط قوت کوئریها را نشان دهد و بهینهسازیهای مورد نیاز را مشخص کند. از ابزارهایی مانند SQL Server Management Studio SSMS یا Query Store برای بررسی و تحلیل نقشههای اجرا استفاده کنید.
در SQL Server، اپراتورهای فیزیکی Aggregate برای انجام عملیات Aggregate (مانند SUM، AVG، MIN، MAX و COUNT) بر روی دادهها استفاده میشوند. دو نوع اصلی از اپراتورهای Aggregate در SQL Server شامل Stream Aggregate و Hash Aggregate هستند. در ادامه هر کدام از این اپراتورها بررسی میشود:
1. Stream Aggregate (Aggregate جریانی):
– این اپراتور برای انجام عملیات Aggregate بر روی دادههای مرتب استفاده میشود. در صورتی که دادهها مرتب شده باشند و نیاز به عملیات Aggregate با گروهبندی ساده است، این اپراتور معمولاً انتخاب میشود.
– Stream Aggregate برای عملیاتی مانند SUM، AVG، MIN، MAX و COUNT استفاده میشود.
– در نقشه اجرا، Stream Aggregate به عنوان Stream Aggregate نمایش داده میشود.
2. Hash Aggregate (Aggregate هش):
– این اپراتور برای انجام عملیات Aggregate بر روی دادههای نامرتب استفاده میشود. در صورتی که دادهها نامرتب یا نیاز به گروهبندی پیچیدهتر و گستردهتر باشد، این اپراتور معمولاً انتخاب میشود.
– Hash Aggregate ابتدا دادهها را با استفاده از تابع هش به گروههایی تقسیم میکند و سپس عملیات Aggregate را بر روی هر گروه انجام میدهد.
– در نقشه اجرا، Hash Aggregate به عنوان Hash Match (Aggregate) نمایش داده میشود.
بررسی این اپراتورهای Aggregate در نقشه اجرا و درک میزان استفاده از هرکدام در کوئریهای خود میتواند به بهبود عملکرد کوئریها کمک کند. استفاده از ابزارهای مانیتورینگ و تحلیل مانند SQL Server Management Studio (SSMS) برای بررسی و تحلیل نقشه اجرا و عملکرد کوئریها توصیه میشود.
بررسی Loop, Merge, Hash join Hint
در SQL Server، میتوانید با استفاده از Hintهای Join مشخص کنید که موتور پایگاه داده از کدام نوع Join استفاده کند. این Hintها به سیستم پیشنهاد میدهند که از Nested Loop Join، Merge Join یا Hash Join استفاده کند. در زیر، بررسی مختصری از هر یک از این Hintها آورده شده است:
LOOP JOIN:
این Hint به موتور پایگاه داده میگوید که از Nested Loop Join استفاده کند. Nested Loop Join عملیات Join را با استفاده از حلقه تودرتو انجام میدهد و معمولاً برای اتصال دو جدول کوچک به یکدیگر استفاده میشود.
مثال:
SELECT *
FROM Table1
INNER LOOP JOIN Table2 ON Table1.ID = Table2.ID;
MERGE JOIN:
این Hint به موتور پایگاه داده میگوید که از Merge Join استفاده کند. Merge Join برای ادغام دو مجموعه مرتب داده استفاده میشود و معمولاً برای اتصال دو جدول بزرگ به یکدیگر استفاده میشود. مثال:
SELECT *
FROM Table1
INNER MERGE JOIN Table2 ON Table1.ID = Table2.ID;
Hash Join Hint:
این اشاره به موتور پایگاه داده میگوید که از Hash Join برای اجرای Join استفاده کند.
Hash Join برای اتصال دو مجموعه داده نامرتب استفاده میشود و معمولاً برای اتصال دو جدول بزرگ و نامرتب استفاده میشود.
مثال استفاده از این اشاره:
SELECT *
FROM Table1
INNER HASH JOIN Table2 ON Table1.ID = Table2.ID
استفاده از این اشارهها میتواند به بهبود عملکرد کوئریها کمک کند، اما توجه داشته باشید که باید با احتیاط استفاده شوند، زیرا این اشارهها میتوانند تصمیمگیریهای بهینهسازی موتور پایگاه داده را تغییر دهند و در برخی مواقع ممکن است به جای بهبود، عملکرد را بدتر کنند. بهتر است قبل از استفاده از این اشارهها، با تستهای مختلف و بررسیهای دقیق، تأثیر آنها را بر روی کوئریهای خود بررسی کنید.
بررسی NoExpancd Expand Hint
1 – NOEXPAND Hint:
- این اشاره به موتور پایگاه داده میگوید که از ایندکسهای نامبنیاد در اجرای کوئری استفاده نکند و آنها را باز نکند. به عبارت دیگر، موتور پایگاه داده مجاز است ایندکسهای نامبنیاد را برای بهینهسازی کوئری استفاده نکند.
- این اشاره معمولاً در صورتی استفاده میشود که میخواهید اطمینان حاصل کنید که موتور پایگاه داده از ایندکسهای نامبنیاد استفاده نمیکند و کوئری باید همواره با استفاده از پلن کوئری معمولی اجرا شود.
- مثال استفاده از این اشاره:
SELECT *
FROM Table1 WITH (NOEXPAND)
WHERE ...
2 – EXPAND Hint:
- این اشاره به موتور پایگاه داده میگوید که از ایندکسهای نامبنیاد در اجرای کوئری استفاده کند و آنها را باز کند.
- این اشاره معمولاً در صورتی استفاده میشود که میخواهید موتور پایگاه داده را به استفاده از ایندکسهای نامبنیاد تشویق کنید و بهینهسازیهای لازم را اعمال کنید.
- مثال استفاده از این اشاره:
SELECT *
FROM Table1 WITH (EXPAND)
WHERE ...
استفاده از این اشارهها ممکن است در برخی مواقع برای بهبود عملکرد کوئری مفید باشد، اما باید توجه داشت که استفاده از آنها باید با دقت صورت گیرد و قبل از استفاده باید تأثیر آنها را بر روی عملکرد کوئریها بررسی کرد. در برخی موارد، استفاده نادرست از این اشارهها میتواند به جای بهبود، عملکرد را بدتر کند.
بررسی Plan Caching در SQL Server
بررسی Plan Caching یکی از جنبههای مهم و کلیدی در عملکرد SQL Server است. Plan Caching به معنای ذخیره و استفاده مجدد از نقشههای اجرا (Execution Plans) برای کوئریهای مختلف است. وقتی یک کوئری ارسال میشود، SQL Server تلاش میکند تا نقشهای اجرا که برای آن کوئری مناسب است را از Plan Cache دریافت کند و در صورت وجود، از آن استفاده کند. این عملکرد میتواند به بهبود عملکرد و کارایی کوئریها و کاهش بار بر روی سرور کمک کند.
در زیر چند نکته مهم درباره Plan Caching در SQL Server ذکر شده است:
- آشنایی با Plan Cache: Plan Cache یک بخش از حافظه است که نقشههای اجرا برای کوئریهای اجرا شده قبلی در آن ذخیره میشوند. این اطلاعات شامل نوع کوئری، محاسبهها و ترتیب عملیات است.
- بهبود عملکرد: Plan Caching میتواند بهبود عملکرد و کارایی کوئریها را ارتقاء دهد، زیرا اجرای مجدد یک کوئری با استفاده از یک نقشه اجرا ذخیره شده در Plan Cache معمولاً سریعتر است.
- Plan Cache بر اساس نوع کوئری: Plan Cache برای هر نوع کوئری (SELECT، INSERT، UPDATE، DELETE) جداگانه مدیریت میشود. هر کوئری با توجه به پارامترهای ورودی خود و دقیقهترین جزئیات آن در Plan Cache ذخیره میشود.
- مواردی که تأثیر Plan Cache را میگیرند: تغییرات در Schema، ایجاد یا حذف ایندکسها، تغییرات در ترتیب عملیات و افزایش تغییرات در دادهها میتواند تأثیر مستقیمی بر Plan Cache داشته باشد و باعث از بین رفتن نقشههای اجرا موجود و تولید نقشههای جدید شود.
- مدیریت Plan Cache: SQL Server به طور خودکار مدیریت Plan Cache را انجام میدهد، اما میتوانید با استفاده از ابزارها و روشهایی مانند اشارهها (Hints)، انجام تاکتیکهای کارآمد مانند بستن و بازکردن دستورات (Statement) و Clear کردن Plan Cache، برخی از تصمیمات مدیریتی را در این زمینه اتخاذ کنید.
- رصد و بررسی عملکرد: برای ارزیابی عملکرد Plan Cache و تأثیرات آن بر عملکرد سرور، باید به صورت مداوم عملکرد آن را رصد و بررسی کرد و در صورت نیاز، اقداماتی مانند اصلاح کوئریها و بهینهسازی Plan Cache را انجام داد.
با رصد، مدیریت و بهینهسازی Plan Cache، میتوانید کارایی و عملکرد کلی سرور SQL Server خود را بهبود بخشیده و تأثیر مستقیمی بر عملکرد کوئریها داشته باشید.
مروری بر مکانیزم Cache کردن Execution Plan در SQL Server
مکانیزم Cache کردن Execution Plan یکی از ویژگیهای مهم در SQL Server است که به بهینهسازی عملکرد سیستم کمک میکند. در اینجا یک مرور کلی بر مکانیزم Cache کردن Execution Plan ارائه شده است:
1. Execution Plan:
– Execution Plan نقشهای است که SQL Server برای اجرای یک کوئری تولید میکند. این نقشه شامل ترتیب عملیات، نوع Joinها، استفاده از ایندکسها و دیگر اطلاعات مورد نیاز برای اجرای کوئری است.
2. Plan Cache:
– Plan Cache یک بخش از حافظه است که Execution Plans کوئریهای اجرا شده قبلی در آن ذخیره میشوند. این اطلاعات شامل نقشههای اجرا برای کوئریها و Store Procedures میباشد.
3. Ad Hoc و Prepared Queries:
– Ad Hoc Queries کوئریهایی هستند که به صورت دینامیک تولید میشوند و هر بار اجرا میشوند. در این حالت، Execution Plan هر کوئری در Plan Cache ذخیره میشود.
– Prepared Queries همانند Store Procedures هستند و قبل از اجرا آماده میشوند. Execution Plan برای این نوع کوئریها در Plan Cache ذخیره میشود و میتواند برای اجراهای آینده استفاده شود.
4. Parameter Sniffing:
– Parameter Sniffing وقتی رخ میدهد که یک کوئری با استفاده از یک پارامتر اجرا میشود و SQL Server از Execution Plan مربوط به آن پارامتر برای سایر اجراها استفاده میکند. این بهینهسازی میتواند باعث بهبود عملکرد باشد.
5. Recompilation:
– برخی تغییرات در محیط میتوانند باعث بازنویسی (Recompilation) Execution Plan شوند. به عنوان مثال، تغییرات در Schema، افزایش تغییرات در دادهها و تغییرات در ترتیب عملیات ممکن است این اقدام را فراخوانی کنند.
6. آشنایی با Dynamic Management Views (DMV):
– DMVها مانند `sys.dm_exec_query_stats` و `sys.dm_exec_cached_plans` به شما اطلاعات جامع در مورد Plan Cache و استفاده از Execution Plans را فراهم میکنند. این اطلاعات میتوانند برای مانیتورینگ و بهینهسازی استفاده شوند.
7. Maintenance Tasks:
– در مواردی که نیاز به تازهسازی یا پاکسازی Plan Cache است، میتوان از رویدادها و وظایف نگهداری مانند `DBCC FREEPROCCACHE` یا `sp_recompile` استفاده کرد. این اقدامات باید با احتیاط انجام شوند و تأثیرات آنها روی کارایی دقیقاً درنظر گرفته شود.
با استفاده از این مکانیزم Cache کردن Execution Plan، SQL Server توانایی بهینهسازی اجرای کوئریها و کاهش زمان پاسخ به درخواستها را داراست. اما همواره باید با دقت از این ویژگی استفاده شود و تغییرات محیط را مدیریت کرد تا عملکرد بهینه حفظ شود.
آشنایی با Plan Cache در SQL Server
Plan Cache در SQL Server یک بخش از حافظهی سرور است که Execution Plans کوئریهایی که قبلاً اجرا شدهاند، را ذخیره میکند. این کارها میتواند بهبود عملکرد سرور را ایجاد کند، زیرا اجرای مجدد یک کوئری با استفاده از یک Execution Plan ذخیره شده، معمولاً سریعتر از اجرای مجدد کوئری بدون استفاده از Execution Plan است.
بعد از اجرای یک کوئری، SQL Server تلاش میکند تا Execution Plan مربوط به آن کوئری را در Plan Cache پیدا کند. اگر Execution Plan موجود باشد، سرور از آن استفاده میکند و اجرای مجدد کوئری را تولید نمیکند. اگر Execution Plan موجود نباشد، سرور یک Plan جدید تولید میکند و آن را به Plan Cache اضافه میکند تا برای اجراهای بعدی مورد استفاده قرار گیرد.
Plan Cache برای هر نوع کوئری (SELECT، INSERT، UPDATE، DELETE) جداگانه مدیریت میشود. این به این معنی است که برای هر نوع عملیات، Execution Plans جداگانه در Plan Cache ذخیره میشوند. همچنین، SQL Server قادر به استفاده مجدد از Execution Plans برای کوئریهای Ad Hoc (کوئریهایی که هر بار با اجرای مجدد تولید میشوند) و کوئریهای Prepared (مانند Store Procedures) است.
برای مدیریت و رصد Plan Cache، میتوانید از ابزارهای مانیتورینگ مانند دستورات دینامیک (Dynamic Management Views) و توابع سیستمی (System Functions) در SQL Server استفاده کنید. این ابزارها اطلاعات جامع در مورد Plan Cache و استفاده از Execution Plans را فراهم میکنند که میتواند برای رصد و بهینهسازی عملکرد سرور بسیار مفید باشد.
بررسی DMV های مربوط به مشاهده Plan Cache
در SQL Server، از دستورات دینامیک (Dynamic Management Views یا DMV) و توابع سیستمی برای مشاهده اطلاعات Plan Cache و Execution Plans استفاده میشود. این اطلاعات میتوانند برای رصد و تحلیل عملکرد کوئریها و بهینهسازی Plan Cache بسیار مفید باشند. در زیر، چند DMV معمولاً برای مشاهده Plan Cache استفاده میشوند:
sys.dm_exec_cached_plans
:- این DMV اطلاعاتی در مورد Execution Plans ذخیره شده در Plan Cache را فراهم میکند.
- میتوانید از این DMV برای مشاهده اطلاعاتی مانند Query Hash، Plan Handle، Creation Time و موارد دیگر استفاده کنید.
- نمونه کوئری:
SELECT *
FROM sys.dm_exec_cached_plans
sys.dm_exec_query_stats
:
- این DMV اطلاعات آماری در مورد کوئریها و Execution Plans مربوط به آنها را فراهم میکند.
- میتوانید از این DMV برای مشاهده اطلاعات مانند Total Logical Reads، Total Logical Writes، Total Worker Time و موارد دیگر استفاده کنید.
- نمونه کوئری:
SELECT *
FROM sys.dm_exec_query_stats
sys.dm_exec_sql_text
:
- این DMV متن کوئریهای اجرا شده را نمایش میدهد، که میتواند برای پیدا کردن متن دقیق یک کوئری استفاده شود.
- میتوانید از این DMV برای مشاهده متن کوئریها با استفاده از
sql_handle
دریافت شده از DMVsys.dm_exec_cached_plans
استفاده کنید. - نمونه کوئری:
SELECT *
FROM sys.dm_exec_sql_text(sql_handle)
sys.dm_exec_plan_attributes
:
- این DMV اطلاعات مربوط به ویژگیهای یک Plan را فراهم میکند. به عنوان مثال، میتوانید ویژگیهایی مانند IsParallelPlan و ParallelWorkerCount را بررسی کنید.
- نمونه کوئری:
SELECT *
FROM sys.dm_exec_plan_attributes(plan_handle)
sys.dm_exec_query_plan
:
- این DMV Execution Plan مربوط به یک Plan Handle را نمایش میدهد.
- میتوانید از این DMV برای مشاهده Execution Plan با استفاده از
plan_handle
دریافت شده از DMVsys.dm_exec_cached_plans
استفاده کنید. - نمونه کوئری:
SELECT *
FROM sys.dm_exec_query_plan(plan_handle)
این DMVها و توابع سیستمی میتوانند به شما کمک کنند تا Plan Cache را مشاهده و تحلیل کنید و از آنها برای بهینهسازی و رصد عملکرد کوئریها و استفاده از Execution Plans بهرهمند شوید.
بررسی دستورات مدیریت Plan Cache
دستورات مدیریت Plan Cache برای کنترل و مدیریت حافظهی مخصوص Plan Cache در SQL Server استفاده میشوند. این دستورات به شما امکان میدهند تا Execution Plans را از حافظهی Plan Cache حذف کنید، بخشی از حافظه را آزاد کنید یا کل Plan Cache را پاک کنید. در زیر، توضیح مختصری از چند دستور مدیریت Plan Cache آورده شده است:
1 – DBCC FREEPROCCACHE:
- این دستور برای حذف تمامی Execution Plans موجود در Plan Cache استفاده میشود.
- استفاده از این دستور میتواند منجر به بازنویسی و بازسازی تمامی کوئریها باشد و تأثیر زیادی بر عملکرد سرور داشته باشد.
- نمونه استفاده:
DBCC FREEPROCCACHE;
2 – DBCC FREEPROCCACHE (plan_handle):
- این فرمان برای حذف یک Execution Plan خاص با استفاده از plan_handle آن استفاده میشود.
- با استفاده از این فرمان، میتوانید فقط یک Execution Plan خاص را از Plan Cache حذف کنید.
- نمونه استفاده:
DBCC FREEPROCCACHE (0x06000100E6BD970EC050F7C90100000001000000000000000000000000000000000000000000000000000000);
3 – DBCC FREESYSTEMCACHE (‘CACHESTORENAME’):
- این دستور برای حذف Execution Plans موجود در یک Cache Store خاص استفاده میشود.
- با استفاده از این دستور، میتوانید تنها Execution Plans مربوط به یک نوع خاص از Cache Store (مانند Object Plans یا SQL Plans) را حذف کنید.
- نمونه استفاده:
DBCC FREESYSTEMCACHE ('SQL Plans');
4 – ALTER DATABASE SCOPED CONFIGURATION CLEAR PROCEDURE_CACHE:
- این دستور برای حذف تمامی Execution Plans موجود در Plan Cache برای یک دیتابیس خاص استفاده میشود.
- با استفاده از این دستور، میتوانید تنها Plan Cache برای یک دیتابیس خاص را پاک کنید.
- نمونه استفاده:
ALTER DATABASE SCOPED CONFIGURATION CLEAR PROCEDURE_CACHE;
با استفاده از این دستورات، میتوانید به صورت دقیق تر عملکرد و مدیریت حافظهی مخصوص Plan Cache را کنترل کنید و در صورت نیاز، از حافظهی آن برای استفادهی بهینهتر از منابع سرور استفاده کنید. اما باید توجه داشت که استفاده از این دستورات باید با احتیاط انجام شود و تأثیر آنها بر عملکرد کلی سرور را به دقت بررسی کرد.
بررسی استفاده مجدد از Execution Plan
استفاده مجدد از Execution Plan یکی از راههای بهینهسازی عملکرد کوئریها در SQL Server است. زمانی که یک کوئری اجرا میشود، SQL Server تلاش میکند تا Execution Plan مربوط به آن کوئری را از Plan Cache یا سری کنترل کش ذخیرهسازی دیگر بخواند. اگر Execution Plan موجود باشد، سرور از آن استفاده میکند به جای تولید مجدد آن، که میتواند زمانبر باشد.
مزایای استفاده مجدد از Execution Plan عبارتند از:
1. کاهش بار بر سرور: استفاده مجدد از Execution Plan منجر به کاهش بار بر سرور میشود، زیرا نیازی به تولید مجدد Execution Plan برای هر کوئری نیست و از پردازش مجدد کوئریها جلوگیری میشود.
2. کاهش زمان پاسخ: با استفاده مجدد از Execution Plan، زمان پاسخ به کوئریها کاهش مییابد، زیرا اجرای مجدد Execution Plan نیازی نیست و نتیجه به سرعت برگردانده میشود.
3. کاهش بار بر حافظه: هر Execution Plan که در Plan Cache ذخیره میشود، حافظه را اشغال میکند. استفاده مجدد از Execution Plan منجر به کاهش مصرف حافظه توسط Plan Cache میشود.
برای اطمینان از استفاده مجدد موثر از Execution Plan، باید از ابزارها و روشهای بهینهسازی استفاده کرد. برخی از این روشها عبارتند از:
– استفاده از پارامترهای بایند شده: با استفاده از پارامترهای بایند شده در کوئریها، SQL Server میتواند Execution Planهای مشابه را برای کوئریهای مختلف استفاده کند.
– بهینهسازی کوئریها: با بهینهسازی کوئریها و ایجاد شرایطی که باعث شود که اجرای مجدد یک Execution Plan با تغییرات کوچک انجام شود، میتوانید از استفاده مجدد بهینهتری از Execution Plan برخوردار شوید.
– مرور و تحلیل Plan Cache: با مرور و تحلیل محتویات Plan Cache، میتوانید از استفاده مجدد بهینهتری از Execution Plan برخوردار شوید و از روشهای بهینهسازی مناسب استفاده کنید.
با استفاده از این روشها و رویکردهای بهینهسازی، میتوانید از استفاده مجدد بهینهتری از Execution Plan و بهبود عملکرد کلی سرور خود بهرهمند شوید.
دیدگاه ها 2