1 -تا جائیكه امكان دارد سیع كنید از عبارت WHERE در دستورات SELECT خود استفاده كنید.
3 -تا حد امكان از بکارگ یی Cursor اجتناب كنید .
سیع کنید منطق Cursor ای که دارید از آن استفاده یم کنید را با کمک روش های based-set پیاده سازی کنید.
ییک از دالیل اینکه از Cursor ها رصف نظر یم شود این است که در حلقه ی کررس هر عبارت FETCH معادل با یک عبارتSELECT
است که هزینه ی زیادی خواهد داشت.
 ی كه نیاز نیست از آن به هیچ عنوان استفاده 
4 -در مورد اینكه آیا SELECT شما واقعا به DISTINCT نیاز دارد یا نه توجه كنید. در جا
نكنید.
 ی را ذكر كنید كه استفاده یم كنید. لذا از عبارت * SELECT تا حد امكان خوددار ی 
5 -در عبارت SELECT خود ، فقط اسایم فیلدها
* باعث یی كنید. زیرا استفاده از اثر شدن ایندکس هامیگردد.
6 -دستور ROWCOUNT SET همان كار ی را انجام یم دهد كه گز ینه TOP در دستور SELECT اما گز ینه TOP به مراتب كاراتر است.
7 -تا حد امكان از EXISTS و IN به جای NOT EXISTS و IN NOT استفاده كنید ز یرا Performance سیستم را افزایش یم دهند.
8 -ا ز Constraint ها در صورت نیاز استفاده كنید. مانند گز ینه های Constraint و یا Default ها.
9 -از چند Constraint برای انجام ی ل استفاده نكن
ر
ككنی ید. مثال اگر از محدودیتهای Key Primary و Key Foreign برای ل
كنی ر
یض جامعیت ارجایع (Integrity Refrentional (استفاده یم كنید، مواقع
در بع ل ا
ر
كنی ین مطلب در Trigger ن
ی
 ی تنها ی
ی
ك بار اضاف به 
سیستم تحمیل یم كند.
 -10
ی
زمای كه برای انجام یك درخواست هم یم توان از Join استفاده كرد هم از SubQuery ، استفاده از Join توصیه یم شود چون 
یاست.
ر
رس یع
ر 11 -اگر در عبارت خود هم یم توانید از IN استفاده كنید هم از EXISTS ، است
بهی از EXISTS استفاده كنید چون كارا تر و رس ی
ی ر
عمل یم كند.
13 -تا جائیكه امكان دارد ، سیع كنید از ( )SUBSTRING در عبارت WHERE خود استفاده نكنید.زیرا باعث یم شود كه جدول Scan
شود به جای اینكه از Index استفاده كند.
) البته موضوع تنها Substring نیست، در حالت های دیگه هم میتونه اتفاق بیافته .چون Optimizer نیاز داره عبارت مورد جستجوی 
رت وسطکلمه ای رو بخواهید، ایندکس کمیک نمیکنه
ررسوع شده باشه که در ایندکس موجوده. پس وق
ر
شما با عباری .این حالت برای تابع
RIGHT هم میتونه اتفاق بیافته.(
ررس 14 -تا جائیكه امكان دارد از توابع تبدییل ط
در WHERE استفاده نكنید.
ی 17 -تا زم
ای كه واقعا نیاز ی ندار ید از DISTINCT یا BY ORDER استفاده نكنید.
مت wildcardی رو ی CHAR یا VarCHAR ز یاد استفاده یم شود ( % Like ، (از امكانات Full یت 18 -اگر در برنامه تان از جستجو ی
Search Text استفاده كنید. اگر جستجو در حدی هست که دردرس نگهداری FTS رو داره.
 ی را داشته باشید ، از 
19 -شما یم توانید از BY GROUP با / بدون توابع Aggregation استفاده كنید. اما اگر یم خواهید باالتر ین كارا
BY GROUP بدون توابع Aggregation استفاده نكنید.
20 -تا آنجا كه امكان دارد از Table Derived ها به جای Table Temporary ها استفاده كنید.
ررس 21 -ط
اگر در WHERE از توابیع رو ی فیلد ها ، استفاده شود كه Sargable-Non باشند ، باعث پا
ی
 ی یم ی ی آمدن كارا
شود. اگر 
ررس WHERE بتوانید به شكیل ط
را بازنگر ی كنید كه فیلد و تابع جدا گانه باشند، در این صورت Query یم تواند از Index موجود 
 ی استفاده كر ده و كارا
را افزایش دهید. به کد زیر دقتکنید:
 I)

SELECT ID,First_name,LastName From Members WHERE 
 DATEDIFF(yy,DateOfBirth,GetDate())>21

 II)

SELECT ID,First_Name,Last-Name From Members WHERE 
 DateofBirth<DATEADD(yy,-21,GetDate())

 ی كه مرتب در WHERE ، BY ORDER ،BY GROUP ،TOPو DISTINCT استفاده یم شوند ، 
22 -ایندكس باید رو ی تمام فیلدها
زده شود.
23 -طبق قانون Thumb ، تمام جداول حداقل یك Index Clustered داشته باشند. عموما، نه همیشه، Index Clustered باید 
 ی رو ی فیلدها
 ی زده شوند كه مقادیرش به صورت یكنواخت افزایش پیدا یم كنند ، مانند فیلدهای Identity و یا فیلدها
 كه مقادیرشان 
از یط Key Primary ررس افزایش یم یابند و Unique هستند. در بسیار ی ا
ر
بهیین انتخاب برای Index Clustered است.
اما PK ررس یک PK خوب میتونه دو خصوصیت مهم داشته باشه: Increasing Ever وNarrow . ایط نه چندان نادری وجودداره که
بسیار م Hot یض نمیکنیم. همچن ی Increasing Ever بودن برای PK ه و روی هارددیسک ی ررس رو Clustered ایط خایص وجودداره که
Spot بوجود میاره. این مورد باید به تناسب سناریو بحث بشه.
ی 25 -دقت كنید 
كه به طور تصادف ، ایندكس مشابه رو ی جداول نزنید. ای
 
ن اتفاق ممكن است به سادگ اتفاق بیافتد.برای مثال ، شما 
 ی یك Unique یا Key Primary رو ی یك فیلد تعر یف یم كنید، در اینصورت اتوماتیك ایندكس ها
رو ی این فیلد زده یم شود . اما اگر 
شما به این مسئله توجه نكنید و جداگانه رو ی این فیلد اینكدس بزنید، دچار مشكل ایندكس های تكرار ی یم شو ید.
26 -عموما در موارد ز یر ایندكس زده نیم شود:
ر • اگر Optimizer Query از ایندكس استفاده نكند. ا از ا
مثال اگرجدولكوچك باشد، اكی یندكس استفاده نیم شود.
 ی • فیلد یا فیلدها
 كه قرار است در ایندكس باشند ،عر یض باشند.
 • اگر فیلدها از نوع Text یا Ntext یا Image باشند.
 • اگر از جدول به ندرت استفاده شود.
یی است كه یك ایندكس مركب را به چندین ایندكس تك فیلدی تجز یه كنید. چون عمال فیلد اول توسط
27 -گایه اوقات ایده خو
ر Optimizer Query استفاده یم شود. البته این بدین معنا نیست كه همیشه Index Single از Index Composite عمل یم
ها بهی 
 ی كنند. فقط با تست كردن یم توانید بفهمید كه كدامیك برای جدول شما كارا
بی
ر
شیی دارد.
ر 28 -اگر دو یا چند جدول دار ید كه مرتبا آنها را به یكدیگر Join یم كنی
 ی كه در Join كت دارند ا
ررس د ، بهیاست رو ی فیلدها
یندكس 
بزنید.
عی یند کسهای غ ی ر 29 -تا جائیكه امكان دارد ایندكس Unique ایجاد كنید. زیرا Server SQL رو ی ایندكس های Unique رس ی از ا
Unique یم تواند جستجو كند.
یرص ی 30 -از فیلدهای Float و Real برای Key Primary استفاده نكنید. ز یرا یك Overhead غ ی ور
به سیستم تحمیل یم كند كه 
 ی س كارا
یستم را یم كاهد.
 ی كه رو ی آنها Index Clustered-Non زده شده است، Index Clustered نزنید.
31 -هیچگاه رو ی فیلدها
 ی كه مرتب Update یم شود خوددار ی كنید. ز یرا هروقت فیلدی كه در یك Clustered
32 -از Index Clustered زدن رو ی فیلدها
Index استفاده شده تغی ی یم كند، تمام Index Clustered-Non ها هم باید Update شوند.
 ی را برای Index Clustered انتخاب یم كنی
ر 33 -فیلد یا فیلدها
دكه شامل اطالعای هست كه در Query ها بی
شی Search یم ر
شوند.
ی 34 -Key Primary ی كه شما رو ی جداولتان استفاده یم كنید ، حتما نباید همیشه Index Clustered
باشند. زمای Key Primary
را Index Clustered كنید كه مرتبا Query Range رو ی Key Primary انجام یم دهید یا یم خواهید خروجیتان بر اساس Primary
Key مرتب شود.
35 -تا جاییكه امكان دارد از Index Clustered زدن رو ی فیلد GUID خوددار ی كنید.
36 -در اول تمام Procedure Stored های خود از دستور ON NOCOUNT SET استفاده كنید.
38 -بجای استفاده از NTEXT, TEXT و IMAGE حتما از (MAX(NVARCHAR و (MAX(VARBINARY استفاده کنید.
 ی از جنس Table استفاده كنید.
39 -اگر در برنامه تان از Table Temporary ز یاد استفاده یم كنید، به جای آن سیع كنید از متغ یها
40 -Time Date را هیچگاه به عنوان Key Primary در نظر نگ یید.
41 -اگر این انتخاب را دار ید كه برای ملزم كردن Rules و Default ها از Trigger یا Constrain CHECK استفاده كنید. ترجیحا از
Constrain CHECK استفاده كنید.
ر 42 -برای كاهش Overhead
،كمیین كد ممكن را در Trigger بنو یسید.
43 -تا جاییكه ممكن است از Back Roll كردن تا حد امكان در Trigger خوددار ی كنید. سیع كنید قبل از اینكه Trigger اجرا شود ، 
مشكل را برطرف كنید.
44 -برای ایجـاد جـداول موقت )در صورتیكه چاره ای جز استفـاده از آنها ندار ید( ، از INTO SELECT استفاده نكنید.

افزایش Performance درSP 
1-در نام های SP از "sp "_استفاده نکنید. زیرا این عالمت مخصوص sp های سیستیم موجود در جدول master یم باشد و هنگایم 
که از این اختصار استفاده میکنید سیستم ابتدا بدنبال این نام در جداول سیستیم میگردد. پس از آن اگه پیدا نکرد با ownerDBO به 
ی دنبال آن میگردد باعث یم
که هم ی شود کیل از رسعت اجرای sp کاهش پیدا کند.
2 -در داخل یک SP است به جای اینکه داخل آن
ر
بهی از دو دستور Select استفاده کرد، هرکدام را در داخل یک SP قرار داده و آنرا به 
هنگام نیاز اجرا کنیم. به مثال زیر توجه نمایید:

create Stored procedure dbo.SPTest @query bit
as
if @query=0
select * from authors
else
select * from publishers
go

است از ن
ر
بهی مونه زیر استفاده شود.

create Stored procedure dbo.SPTest @query bit
as
if @query=0
Exec sptestFromauthors
else
Exec spTestfrompublishers
go
//-----------------//
create Procedure dbo.spTestfromAuthors as
select * from Authors
go
//-----------------//
Create Procedure dbo.spTestFromPublishers as
Select * from Publishers
go

رت دارد؟
دلیل استفاده ازکد زیرچیست و نسبت به کد باال چه مزی
در داخل هر sp فقط یک Query میتواند در داخل SQL cache قرارگ ید. وچون داخل SP اول دو query یم باشد، هر دفعه که این
ی SP اجرا شود مجدد SP رسعت آنرا خواهدگرفت
کامپایل خواهد شد و هم ی .
در اول ی Compile یم شود و برای آن Plan Execution بدست یم آید . این Plan در دفعات بعدی اجرا، SQL ی هر SP مرتبه اجرا
 ی راهنما و باکمککد ی Server ر ا میکنه تا با استفاده
ازچه الگوریتم ها ام Index ها به اجرای Query بریدازد و نیازی نیست مجددا 
اینها تحلیل بشن )کاری که در مرحله Compile انجام یم شود(.
 ی نکته 1 :در SP که نیاز نیستکاربر متوجه
ها شود چه تعداد ردیف تحت تاث یقرارگرفته است،
در اول
ً
حتما SP دستور On NoCount Set را بنویسید. زیرا اگر این دستور را صورتگرفته ،
ر
ننویسید هربارکه عملیای SQL تعداد 
یرص د و هم ی وری ی ردیف های تحت تاث یقرارگرفته را برایکاربر ارسال یم کن باعث یک ترافیک
غ ی روی server , client یم شود.
 ی نکته 2
: تاجا که امکان دار د دستورات داخل SP راکوچک نگه دارید. اینکمک میکند که تعداد Lock ها کم شود و رسعت کیل برنامه 
شما باال بر ود . دو راه برایکاهش طول دستورات SQL موجود است.
1 - که هر مرحله درحد امکان به رسعت
ر
تفکیککردنکارهای یکپارچه به مراحلکوچکی Commit شود .
SQL Server Statement Batches از استفاده سو - 2
ی
، که رفت و برگشت ب ی client و Server ر ا کم میکند.
من شخصا وق Online Books برای اجرای رت ( دنبال این موضوع توی
ً
گشتم به یک نکته برخوردکردم و اونم این بودکه نوشته بود مثال
ر یکSP از
بهی {CAll {استفاده بشه. زیرا این باعث میشه که ازطریق ODBc و با استفاده از پروتکل RPC دستورات مورد نظر اجرا شود 
ک اجرا شدن
ر
ه باعث رسیعی SP نسبت به دستور Execمیشود.من شخصا امتحانکردم و با Profiler هم مشاهده کردم دقیقا 
همینطوره Starting. باRPC انجام میشه دستورات بوسیله SP اجرا میشه و Commit اون باز بوسیله RPC میباشد(
نکته 3 :اگر دستورات داخل SP همیشه ثابت هستند و بصورت دینامیک تعریف نشده اند، خییل خوب است و این کار باعث میشود تا
دارای متغ یمیباشد و هردفعه عوض میشود این یک چ ی ی SQL برای آن یک Plan تشکیل دهد. ویل اگر بوسیله دستور Where ایده آل
ً نیست و هردفعه SP
باید حتما Compile شود و Optimize نخواهد شد.
متغ یهای آن تغی یخواهندکرد، بهی ر اگر شما میدانید که هر دفعه که SP است ابتدای
نیاز به اجراداشته باشد دائما SP دستور Withً 
ً Recompile را بنویسید .این SP را مجبور میکند باید موقع اجرادوباره
که حتما Compile شود ، در این شویدکه
ی
حال شمامطمی 
هربار که SP اجرا شد خود به خود Optimize یم شود.
نکته 4 :برنامه خود را جوری طرایحکنیدکه کاربر امکان لغو یک عملیات را داشته باشد.کاری نکنیدکه کاربر مجبور به reboot کردن 
سیستم شود ، که میتواند باعث تجزیه نشدن مشکالت performance شود.
ر نکته 5
: بیشی SP ها
ر
ها از تعدادی پارامی استفاده میکنند. این به خودی خو میتو
بدی نیست. ویل زمای ی
ی
د چ ی اند باعث مشکل شود که 
ها
ر
اگر پارامی optional های متغ یخییل زیاد باشند هر زمانکه
ر
باشند، و تعداد پارامی sp اجرا یم شود. دو راه برای هندل این مشکل 
هست ییک با بازده آرام و ییک با بازده رسیــع.
ر
یت راه بهیبه کارگ یی منطق ELSE...If داخل SP است، و ایجاد یک query مجزا برای هر از متغ یهاکه درون
ترکیب ممک SP تعریف 
باشیدکه
شده اند. در این راه، شما یم ی
 
توانید مطمی query شما هر زمان که اجرا یم شود کارآمد و موثر هست.
ها گفته یم کاربر ساخته یم ی نکته: query hoc Ad به کوئری
ی
شودکه توسط برنامه بر اساس نیاز آی شوند