數(shù)據(jù)庫設(shè)計(jì)和編碼規(guī)范

Version1.0

目錄

1簡介................................................

1.1讀者對(duì)象..................................................................

1.2目的.......................................................................

2數(shù)據(jù)庫命名規(guī)范......................................

2.1規(guī)范總體要求..............................................................

2.2數(shù)據(jù)庫對(duì)象命名規(guī)范........................................................

2.3變量命名規(guī)范..............................................................

3數(shù)據(jù)庫設(shè)計(jì)規(guī)范......................................

3.1選擇有效的設(shè)計(jì)工具.......................................................

3.2表的設(shè)計(jì)..................................................................

3.2.1遵守范式要求.....................................................

3.2.2字段設(shè)計(jì).........................................................

3.2.3適當(dāng)?shù)暮侠淼娜哂?................................................

3.2.4注意大類型的字段設(shè)計(jì)............................................

3.3表關(guān)系和約束設(shè)計(jì)..........................................................

3.3.1主鍵設(shè)計(jì).........................................................

3.3.2外鍵設(shè)計(jì).........................................................

333檢查約束............................................................

3.4索引的設(shè)計(jì)................................................................

3.4.1聚集索引和非聚集索引.............................................

3.4.2索引的初始創(chuàng)建原則...............................................

3.4.3索引的注意事項(xiàng)...................................................

3.4.4索引的后期維護(hù)工作...............................................

3.5物理存儲(chǔ)設(shè)計(jì)..............................................................

3.5.1Id志文件另外存放.................................................

3.5.2存儲(chǔ)空間的設(shè)計(jì)...................................................

4T?SOL編碼規(guī)范......................................

4.1書寫基本規(guī)范..............................................................

4.2使用可搜索參數(shù)（WHERE使用原則）.........................................

4.3少用觸發(fā)器和禁用游標(biāo).....................................................

4.4聯(lián)合查詢盡可能使用UNIONALL..............................................................

4.5盡可能避免的地方..........................................................

4.6避免返回和使用多余的數(shù)據(jù).................................................

17操作符優(yōu)化................................................................

4.8數(shù)據(jù)庫事務(wù)處理原則........................................................

4.9最少次數(shù)的訪問表..........................................................

4.10避免隱含的數(shù)據(jù)類型轉(zhuǎn)換...................................................

1

4.表變星、臨時(shí)表和公用表達(dá)式的用法…

2

4.正確地判斷記錄是否存在............

4.3

4.注意自定義標(biāo)量函數(shù)的影響..........

44.4

避免編寫復(fù)雜的語句..........

5TSQL

4.6應(yīng)用程序?qū)臃乐箞?zhí)行大塊的TSOL語句

4.

7對(duì)數(shù)據(jù)庫大表的處理方案............

8SPEXECUTESQL代替EXEC..............................

存儲(chǔ)過程的一些建議................

如何進(jìn)行質(zhì)量控制............

5J

規(guī)范的制定、認(rèn)可和實(shí)施................

52

討論和檢查工作........................

53

--對(duì)制定的規(guī)范不斷完善..................

54

--討論和制定公共模板....................

5.4.1SELECT語句...................

5.4.2JOIN語句......................

5.4.3子查詢.........................

544INSERT語句...................

5.4.5UPDATE語句..................

5.4.6DELETE語句..................

5.4.7CASE語句.....................

5.4.8IF語句.........................

5.4.9WHILE語句...................

EXISTS語句...................

變量聲明......................

變量賦值......................

創(chuàng)建表及約束索引..............

存儲(chǔ)過程......................

帶輸出參數(shù)的存儲(chǔ)過程.........

視圖...........................

物化視圖......................

自定義標(biāo)量函數(shù)................

自定義一值函數(shù)（多語句）.....

自定義表值函數(shù)（內(nèi)聯(lián)）.......

索引整理......................

數(shù)據(jù)庫事務(wù)格式................

1.2目的

2一個(gè)合理的數(shù)據(jù)庫結(jié)構(gòu)設(shè)計(jì)是保證系統(tǒng)性能的基礎(chǔ)。一個(gè)好的規(guī)

范讓新手容易進(jìn)入狀態(tài)且少犯錯(cuò)，保持團(tuán)隊(duì)支持順暢，系統(tǒng)長久

使用后不至于紊亂，讓管理者易于在眾多對(duì)象中，獲取所需或理

清問題。

3同時(shí)，定義標(biāo)準(zhǔn)程序也需要團(tuán)隊(duì)合作，討論出大家愿意遵循的規(guī)

范。隨著時(shí)間演進(jìn)，還需要逐步校訂與修改規(guī)范，讓團(tuán)隊(duì)運(yùn)行更

為順暢。

4數(shù)據(jù)庫命名規(guī)范

4.1團(tuán)隊(duì)開發(fā)與管理信息系統(tǒng)講究默契，而制定服務(wù)器、數(shù)據(jù)庫對(duì)象.變量等

命名規(guī)則是建立默契的基本。

4.2命名規(guī)則是讓所有的數(shù)據(jù)庫用戶，如數(shù)據(jù)庫管理員、程序設(shè)計(jì)人員和程序

開發(fā)人員，可以直觀地辨識(shí)對(duì)象用途。而命名規(guī)則大都約定俗成，可以依

照公司文化.團(tuán)隊(duì)習(xí)慣修改并落實(shí)。

4.3規(guī)范總體要求

1.避免使用系統(tǒng)產(chǎn)品本身的慣例，讓用戶混淆自定義對(duì)象和系統(tǒng)對(duì)象或關(guān)鍵詞。例如，存儲(chǔ)過程不

要以sp_或xp_開頭，因?yàn)镾QLSERVER的系統(tǒng)存儲(chǔ)過程以sp_開頭，擴(kuò)展存儲(chǔ)過程以xp_開頭。

2.不要使用空白符號(hào)、運(yùn)算符號(hào)、中文字、關(guān)鍵詞來命名對(duì)象。

3.名稱不宜過于簡略，要讓對(duì)象的用途直觀易懂，但也不宜過長，造成使用不方便。

4.不用為數(shù)據(jù)表內(nèi)字段名稱加上數(shù)據(jù)類型的縮寫。

5.名稱中最好不要包括中劃線。

6.禁止使用［拼音］+［英語］的方式來命名數(shù)據(jù)庫對(duì)象或變量。

4.4數(shù)據(jù)庫對(duì)象命名規(guī)范

我們約定，數(shù)據(jù)庫命名規(guī)范

對(duì)象包括表、視圖

（查詢\存儲(chǔ)過程

（參數(shù)直詢?nèi)牒?/p>

數(shù)、約束。對(duì)象名

字由前綴和實(shí)際名

字組成，長度不超

過30.避免中文和

保留關(guān)鍵字，做到

簡潔又有意義。前

綴就是要求每種對(duì)

象有固定的開頭字

符串，而開頭字符

串宜短且字?jǐn)?shù)統(tǒng)

一。可以討論一下

對(duì)各種對(duì)象的命名

規(guī)范，通過后嚴(yán)格

按照要求實(shí)施。例

如：

對(duì)象

數(shù)據(jù)庫名：［項(xiàng)目英文名稱］+DB

數(shù)據(jù)庫

數(shù)據(jù)文件:［數(shù)據(jù)庫名稱］+_Data.mdf

日志文件:［數(shù)據(jù)庫名稱］+_Log』df

口志文件：［數(shù)據(jù)庫名稱］+_Log』df

前綴T+［表名］;單詞首寫字母為大寫，其余全部小寫。

表

示范:TCustomer

示范：TCustomer

不需要前綴，直接用英文單詞或縮寫，單詞首字母為大寫，其余為小

表字段

寫。例如：UserName,如果是兩個(gè)單詞的首寫字母縮寫，統(tǒng)一用大寫，

比如:UserID

不要用ID,一律用表名+ID（如果表名太長的話，采用縮寫用各單詞的

主鍵所在字段

首寫字母線合）

用P_前綴+［功能描述］（首單詞大寫，其余下寫）

存儲(chǔ)過程

例如:P_GetAllCorps

例如：P_GetAllCorps

用前綴V_+［視圖名稱］

視圖

例如：V_Account

例如：V_Account

前綴F_+［功能描述］（首單詞大寫，其余下寫）

自定義標(biāo)量函數(shù)

例如：F_GetEWSourceName

例如：F_GctEWSourccNamc

前綴TF_+［功能描述］（首單詞大寫，其余下寫）

自定義表值函數(shù)

PK」表名］

主鍵

例如：PK_TExAccounl

例如：PK_TExAccount

用FK」主表名］一字段表表示（考慮到名字會(huì)比較長，突出主表）

外鍵

例如：FK_TOidci_OidciID

例如：FK_TOrder_OrderID

用DF」表名］」字段名］表示

默認(rèn)值約束

例如：DF_TOrder_Type

例如：DP_TOrdcr_Typc

用CK」表名］」字段名］表示

檢查約束

例如：CK_TCustomer_Mail

例如：CK_TCustomcr_Mail

用UQ」表名L［字段名］表示

唯一性約束

例如：UQ_TCustomer_Code

例如：UQ_TCusiomer_Code

用DX」表名］」字段名］表示

聚集索引

例如：DX_TCachct_ID

例如：DX_TCachet_ID

用IX」表名］」字段名］表示(字段名較多時(shí)，取前面兩個(gè)即可)

其它索引

例如：IX_TCachet_CName_CorpID

例如：IX_TCachel_CName_CorpID

4.5變量命名規(guī)范

1.數(shù)據(jù)列參數(shù)

命名格式為@+［列名稱］。

2.示例：@EmployeeID@employee_id

3.非數(shù)據(jù)列參數(shù)

在參數(shù)無法跟列名稱進(jìn)行關(guān)聯(lián)時(shí)，使用能夠反映該參數(shù)功能的英文單詞或單詞組合，采用Pascal樣

式命名。

5示例：@WorkType@work_type

6數(shù)據(jù)庫設(shè)計(jì)規(guī)范

6.1好的數(shù)據(jù)庫架構(gòu)設(shè)計(jì)對(duì)系統(tǒng)運(yùn)行的性能起著很大的作用，所以要在開始

時(shí)就要引起重視。為了保證數(shù)據(jù)庫設(shè)計(jì)的高效必須安排時(shí)間對(duì)設(shè)計(jì)結(jié)果進(jìn)

行評(píng)審，這一環(huán)節(jié)必不可少。

6.2選擇有效的設(shè)計(jì)工具

數(shù)據(jù)庫設(shè)計(jì)工具：、、

PowerDesigner,ERStudioRoseMicrosoftVisioo

項(xiàng)目開始前要確定使用哪種設(shè)計(jì)工具。(另有開發(fā)插件:RedGate系列(SQLPrompt))

選擇的工具要便于討論便入生成腳本導(dǎo)入數(shù)據(jù)庫。

設(shè)計(jì)通過后要形成文檔，并且這個(gè)結(jié)構(gòu)設(shè)計(jì)文檔要存檔，簽入VSS基線庫中。

6.3在進(jìn)行數(shù)據(jù)庫設(shè)計(jì)時(shí)，應(yīng)隨時(shí)進(jìn)行數(shù)據(jù)字典的維護(hù)。（字段要求寫說明）

6.4表的設(shè)計(jì)

6.4.1表設(shè)計(jì)在數(shù)據(jù)庫設(shè)計(jì)中占據(jù)有十分重要的地位。表是實(shí)際存儲(chǔ)

數(shù)據(jù)的對(duì)象。除了要注重表結(jié)構(gòu)設(shè)計(jì)，字段的設(shè)計(jì)之外還要注

意表之間關(guān)系的設(shè)計(jì)。

6.4.2遵守范式要求

通常，合理的規(guī)范化會(huì)最小化數(shù)據(jù)異常和減少數(shù)據(jù)的冗余。為了更新數(shù)據(jù)的正確與快速，在設(shè)計(jì)的初

始階段多采用三范式設(shè)計(jì)數(shù)據(jù)庫表。

第一范式強(qiáng)調(diào)的是列的原子性即列不能夠再分成其他幾列。

643第二范式包含兩層意思，一是表必須有一個(gè)主鍵；二是非主鍵

列必須完全依賴于主鍵，且不能只依賴于主鍵的一部分。（盡量

少使用復(fù)合主鍵）

644第三范式需要確保數(shù)據(jù)表中的所有非主鍵列直接與主鍵列相關(guān),

而不能直接依賴于非主Z:E冽。

6.4.5字段設(shè)計(jì)

1盡量避免可為空的列。

2.雖然在個(gè)別情況下，允許空值可能是有用的，但是應(yīng)盡量少用。這是因?yàn)樾枰獙?duì)它們進(jìn)行特殊處理,

從而會(huì)增加數(shù)據(jù)操作的復(fù)雜性和增加CPU額外的邏輯判斷。很多情況下可以考慮用默認(rèn)值0或空

字符串(")來代替NULL值。所以字段應(yīng)該有NOTNULL的限制。

3.Unicode的選擇。

nvarchar和nchar相應(yīng)比varchar和char要占用更多的存儲(chǔ)空間。設(shè)計(jì)的原則是：如果確保存儲(chǔ)

的內(nèi)容只是純英文和數(shù)字，用如果含有中文字符或其它多國語言，用

char/varcharonchar/nvarcharo

存儲(chǔ)空間補(bǔ)充說明

字段長度要精

確，遵守"必

須、夠用”的

原則。

精確的長度設(shè)

計(jì)既能完整的

描述數(shù)據(jù)，又

可以節(jié)省存儲(chǔ)

空間。積小成

大，當(dāng)數(shù)據(jù)表

中的數(shù)據(jù)有很

多記錄的時(shí)候，

這種存儲(chǔ)空間

的優(yōu)勢就能體

現(xiàn)得十分明

顯。存儲(chǔ)空間

越緊湊，分配

的頁面就越少，

在同樣大小的

內(nèi)存空間中就

可以存儲(chǔ)更多

的頁面，這樣

操作數(shù)據(jù)的效

率就會(huì)提高。

例如能用

char(lO)的就

不要用

char(20),提

高存儲(chǔ)的利用

率和系統(tǒng)性能，

但同時(shí)也要兼

顧擴(kuò)展性和可

移植性。

字段類型

bigint8字節(jié)-2A63(-9,223,372,036,854,775,808)至lj2A63-I

(9,223,372,036,854,775,807)

int4字節(jié)-2A3I(-2,147,483,648)至U2人31-1(2,147,483,647)

smallint2字節(jié)-2A15(-32,768)到2A15-1(32,767)

tinyint1字節(jié)0至lj255

dccimal(9,2)5字節(jié)decimal(9,2)前面的9為精度,后面為小數(shù)位。當(dāng)精度位于

decimal。9,2)9字節(jié)1~9之間時(shí)，占5字節(jié)v當(dāng)精度位于10~19之間時(shí)，占9字

節(jié)。注意,numeric在功能上等價(jià)于decimala

money8字節(jié)-922,337,203,685,477.5808到922,337,203,685,477.5807

smallmoney4字節(jié)-214,748.3648至lj214,748.3647

datetime8字節(jié)精確到3.33亳秒。例如：2014-03-0717:25:39.450

存儲(chǔ)范圍：1753年1月1日到9999年12月31日

存儲(chǔ)范圍：1753年1月1日到9999年12月31日

sinalldatetinie4字節(jié)精確到分鐘，例如:2014-03-0717:24:00

存儲(chǔ)范圍是：1900年1月1日到2079年6月6日

存儲(chǔ)范圍是：1900年1月1日到2079年6月6日

uniqueidentifier16字節(jié)uniqueidentifier數(shù)據(jù)類型可存儲(chǔ)16字節(jié)的二進(jìn)制值，其

作用與全局唯一標(biāo)識(shí)符(GUID)一樣。(CHAR(36))

bit1字節(jié)取值范圍：0或lo

char(n)N字節(jié)

varchar(n)實(shí)際存儲(chǔ)的每個(gè)字符占1字節(jié)

nchar(n)2xN字節(jié)

nvarchar(n)實(shí)際存儲(chǔ)的每個(gè)字符占2字節(jié)

在存儲(chǔ)空間一樣的情況下，字符串?dāng)?shù)據(jù)類型需要字符串匹配操作，這通常比整數(shù)匹配操

作的開銷要大。所以盡量選擇整數(shù)作為字段類型。

646適當(dāng)?shù)暮侠淼娜哂?/p>

降低范式標(biāo)準(zhǔn)的一個(gè)重要原因是為了在檢索數(shù)據(jù)時(shí)少連接表從而提供一個(gè)性能優(yōu)勢。或是預(yù)先匯總計(jì)算

結(jié)果并存放起來，或是將相同字段內(nèi)容一式多份地放在多個(gè)表中，這樣數(shù)據(jù)的冗余會(huì)增加開發(fā)人員的工

作量和業(yè)務(wù)判斷。(最好是對(duì)有冗余的字段要另外用文檔統(tǒng)一說明)

6.4.7完全按照規(guī)范化設(shè)計(jì)的系統(tǒng)幾乎是不可能的，除非系統(tǒng)特別的

小，在規(guī)范化設(shè)計(jì)后，有計(jì)劃地加入冗余是必要的。冗余可以是

冗余數(shù)據(jù)庫,冗余表或者冗余字段，不同粒度的冗余可以起到

不同的作用。冗余可以是為了編程方便而增加，也可以是為了

性能的提高而增加。從性能角度來說，冗余數(shù)據(jù)庫可以分散數(shù)

據(jù)庫壓力，冗余表可以分散數(shù)據(jù)量大的表的并發(fā)壓力，也可以

加快特殊查詢的速度，冗余字段可以有效減少數(shù)據(jù)庫表的連接,

提高效率。

6.4.8數(shù)據(jù)庫設(shè)計(jì)階段，對(duì)必要的冗余處理可以事先安排設(shè)計(jì)，如果

在代碼實(shí)現(xiàn)階段發(fā)現(xiàn)一些必要的冗余字段可以及早提出來考

慮。

649注意大類型的字段設(shè)計(jì)

如果設(shè)計(jì)過程中發(fā)現(xiàn)表中存在大類型(可存儲(chǔ)2G)的字段時(shí)，要慎重考慮，因?yàn)檫@樣的字段會(huì)造成單

一數(shù)據(jù)頁存放不了幾條記錄。而過多的頁面也會(huì)在查詢掃描時(shí)帶來性能影響。

一般的做法是將XML、IMAGE、VARCHAR(MAX).NVARCHAR(MAX)或TEXT類型的字段切割

到另外的數(shù)據(jù)表，而后與主數(shù)據(jù)表一對(duì)一連接。因?yàn)檫@些大型數(shù)據(jù)訪問緩慢，修改時(shí)可能造成記錄鎖定

較久.且在大多數(shù)的使用狀態(tài)下，查詢一般字段內(nèi)容時(shí)可能根本用不到這些字段.這些列的存在會(huì)增加

表的頁面數(shù)，不分割出去容易會(huì)影響其它字段的修改和查詢。

6.5VARCHAR(MAX).NVARCHAR(MAX)字段如果實(shí)際長度在8000以

下，這個(gè)值將被作為常規(guī)的變長數(shù)據(jù)類型來對(duì)待，如果超過8000個(gè)字節(jié),

SQLServer將該值作為TEXT來存儲(chǔ)處理。如果該表數(shù)據(jù)量比較大時(shí),

一定要考慮大字段分離設(shè)計(jì)原則。

6.6少用TEXT和IMAGE,二進(jìn)制字段的讀寫是比較慢的。

6.7表關(guān)系和約束設(shè)計(jì)

6.7.1正確處理表間關(guān)系。一對(duì)多、一對(duì)一、多對(duì)多等關(guān)系。主外鍵

關(guān)系是保證數(shù)據(jù)完整性的一個(gè)重要機(jī)制。維護(hù)數(shù)據(jù)的正確性。

盡量采用提供的約束，如主外鍵、檢查、默認(rèn)值、不可NULL

等。盡可能不要通過程序或存儲(chǔ)過程、觸發(fā)器等機(jī)制來運(yùn)行，畢

竟SQLSERVER約束是在內(nèi)部以優(yōu)化過的二進(jìn)制程序代碼來

實(shí)現(xiàn)的，而其它方式效率當(dāng)然不如直接設(shè)置的約束高。還有，能

夠確定具有唯一值的字段上盡量加上唯一性約束。

6.7.2一些約束在客戶端判斷的確是可以減少服務(wù)器的資源，但是不

能完全保證數(shù)據(jù)的錯(cuò)誤產(chǎn)生。而且用數(shù)據(jù)庫使用域和參照完整

性有時(shí)候還能幫助優(yōu)化器減少查詢執(zhí)行時(shí)間。域和參照完整性

幫助優(yōu)化器分析有效的數(shù)據(jù)值而不需要物理訪問數(shù)據(jù)，這減少

了查詢時(shí)間。

6.7.3主鍵設(shè)計(jì)

?所有的表必須設(shè)置主鍵。主腱跟聚焦索引沒有什么關(guān)系，但主鍵必須要有索引。主鍵的選擇原則：

2.字段值唯一。

3.不可NULLo

4.字段大小盡量最小。

5.字段值不常變更。

6不建議用復(fù)合主鍵。

主健值過大會(huì)影響外表的大小。如果主鍵是聚集索引，由于所有非聚集索引都會(huì)存儲(chǔ)聚集索

引的鍵值，所以主鍵值過大，還將導(dǎo)致其他索引結(jié)構(gòu)的效率不佳（頁面數(shù)1

主鍵關(guān)乎著數(shù)據(jù)的F確性與完整性.而聚焦索引是從數(shù)據(jù)的運(yùn)行效率出發(fā).雖然主鍵跟聚集索引是

兩回事，但基于主鍵的上述特性，所以主鍵往往適合作為表的聚集索引，這也是微軟的默認(rèn)做法。但一些

沒有意義的ID做聚集索引的意義不大，這時(shí)候需要在創(chuàng)建表的時(shí)候給主鍵指定為唯一的非聚集索引。

~主鍵約束（非聚集索引）：

ALTERTABLE[dbo].[TCustomer]ADDCONSTRAINTPK_TCustojnerPRIMARYKEYNONCLUSTERED（ID）;

選擇GUID做為主鍵時(shí)在系統(tǒng)對(duì)接、移值和代碼編寫下都提供了很大的方便，但它是建立在犧牲性

能的基礎(chǔ)上。

1.在實(shí)際運(yùn)用中，如果對(duì)于用36字符的GUID當(dāng)作主鍵時(shí)，應(yīng)當(dāng)注意的問題如下：

2.GUID是無序的，所以不適合用來做聚集索引。否則會(huì)引起頻繁的頁面移動(dòng)而產(chǎn)生大量的碎片。

GUID類型的存儲(chǔ)可以由char(36)改為uniqueidentifier類壁16

個(gè)字節(jié))，以節(jié)省存儲(chǔ)空間。

對(duì)于有關(guān)聯(lián)的表之間，考慮程序方便可用使用GUID做為主鍵，但

對(duì)于獨(dú)立的表，還是以INT類型的字段做為主鍵來設(shè)計(jì)。所以

設(shè)計(jì)階段要分清哪些必須用GUID來做主鍵。

332外鍵設(shè)計(jì)

外鍵的存在會(huì)在處理數(shù)據(jù)時(shí)帶來麻煩，但實(shí)際上這點(diǎn)恰恰是它的好

處。外鍵的存在就最高效的一致性維護(hù)方法。所以在表設(shè)計(jì)時(shí)

要考慮主外鍵的設(shè)計(jì)。如果決定使用外鍵約束，那么所有人必

須遵守嚴(yán)格執(zhí)行。外鍵是最高效的一致性維護(hù)方法，數(shù)據(jù)庫的

一致性要求，依次可以用外鍵、CHECK約束、規(guī)則約束、觸發(fā)

器、客戶端程序，一般認(rèn)為，離數(shù)據(jù)越近的方法效率越高。

3.3.3檢查約束

約束除了主外鍵約束、唯一性約束和默認(rèn)值約束外，還有一類叫檢查約束。

檢查約束是一個(gè)識(shí)別SQLServer表中每行可接受的列值的規(guī)則，檢查約束幫助實(shí)施域的完整性，域完整

性定義了數(shù)據(jù)庫表中列的有效值，檢查約束可以驗(yàn)證單列的域完整性，也可以驗(yàn)證多列的域完整性，在

單個(gè)列上可以有多個(gè)檢查約束，如果插入或更新的數(shù)據(jù)違反了險(xiǎn)查約束，數(shù)據(jù)庫引擎將暫時(shí)停止

INSERT和UPDATE操作。

CREATETABLEdbo.TEmployee(

IDINT,

CodeVARCHAR(20),

SexCHAR(l)CONSTRAINTText_Sex_CKCHECK(Sex='F'ORSex='M'),

Sex列創(chuàng)建相應(yīng)的約束，其值只能是‘F'或'M'值。

ExperienceINTCONSTRAINTText_Experience_CKCHECK(Experience>=0)

--Experience列創(chuàng)建相應(yīng)的約束，其值必須＞-0

):

6.8索引的設(shè)計(jì)

681索引是一把雙刃劍，它通常可以加快數(shù)據(jù)檢索數(shù)據(jù)的同時(shí)，往

往又會(huì)帶來額外的資源開銷（在insert,update和delete使

用時(shí)1有時(shí)候這個(gè)開銷代價(jià)甚至超過了查詢優(yōu)化帶來的好處。

所以，索引的創(chuàng)建是門藝術(shù)，要在工作中不斷的積累經(jīng)驗(yàn)和不

斷的總結(jié)。一般來說，建立索引要看數(shù)據(jù)使用的方式，也就是說

那些訪問數(shù)據(jù)的SQL語句經(jīng)常使用，針對(duì)這些經(jīng)常使用的SQL

語句創(chuàng)建有效的索引還是值得的，但過多的索引又是對(duì)于

OLTP（在線事務(wù)）數(shù)據(jù)庫是不利的。

6.8.2聚集索引和非聚集索引

每個(gè)表只能有一個(gè)聚集索引，因?yàn)槟夸浿荒馨凑找环N方法進(jìn)行排序。

聚集索引和數(shù)據(jù)是混為一體的，而非聚集索引是與數(shù)據(jù)獨(dú)立分開的。

其實(shí)，我們的漢語字典的正文本身就是一個(gè)聚集索引。比如，我們要查"安"字，就會(huì)很自然地翻開字典

的前幾頁，因?yàn)?安"的拼音是"an",而按照拼音排序漢字的字典是以英文字母"a"開頭并以"z"

結(jié)尾的，那么"安"字就自然地排在字典的前部。同樣的，如果查"張"字，那您也會(huì)將您的字典翻到最

后部分，因?yàn)?張"的拼音是"zhang"。也就是說，字典的正文部分本身就是一個(gè)目錄，您不需要再去

查其他目錄來找到您需要找的內(nèi)容。

我們把這種正文內(nèi)容本身就是一種按照一定規(guī)則排列的目錄稱為“聚集索引”。

如果您認(rèn)識(shí)某個(gè)字，您可以快速地從自典中蟄到這個(gè)字。但您也可能會(huì)遇到您不認(rèn)識(shí)的字，不

知道它的發(fā)音，這時(shí)候，您就不能按照剛才的方法找到您要查的字，而需要去根據(jù)"偏旁部首"查到您要

找的字（非聚集索引查找），然后根據(jù)這個(gè)字后的頁碼直接翻到某頁來找到您要找的字（書簽查找X但

您結(jié)合"部首目錄"和"檢字表"而查到的字的排序并不是真正的正文的排序方法，比如您查"張"字,

我們可以看到在查部首之后的檢字表中"張"的頁碼是672頁，檢字表中"張"的上面是"馳"字，但頁

碼卻是63頁，"張"的下面是"弩"字，頁面是390頁。很顯然，這些字并不是真正的分別位于"張"字

的上下方，現(xiàn)在您看到的連續(xù)的"馳、張、顰"二字實(shí)際上就是他們?cè)诜蔷奂饕械呐判颍亲智?/p>

文中的字在非聚集索引中的映射。我們可以通過這種方式來找到您所需要的字，但它需要兩個(gè)過程，先

找到目錄中的結(jié)果，然后再翻到您所需要的頁碼。

通過以上例子，我們可以理解到什么是“聚集索引"和"非聚集索引"。

-聚集索引查找，沒有書簽查找開銷

SELECT*FROM[dbo].[TOrder]

WHEREOrderlD=1

ORDERBYOrderlD;

-非聚集索引查找

SELECTUserID,OrderlDFROM[dbo].[TOrder]

WHEREUserID=1

ORDERBYUserID;

~非聚集索引查找+書簽查找

SELECTUserID,OrderlD,OrderPriceFROM[dbo].[TOrder]

WHEREUserID1

ORDERBYUserID;

6.8.3索引的初始創(chuàng)建原則

如果處在數(shù)據(jù)庫項(xiàng)目的開始，而且不確定如何對(duì)索引建模，可以使用不加思考或默認(rèn)索引模式作為開

始。一旦能夠根據(jù)實(shí)際事務(wù)信息重新評(píng)估數(shù)據(jù)庫后，再調(diào)整索引。所以在系統(tǒng)的初始上線階段一般只考

慮創(chuàng)建最少的、最必要的索引。

1.所有表要有聚集索引，如果沒有合適的字段，那么暫時(shí)在主鍵上創(chuàng)建聚集索引。

2.所有外鍵上創(chuàng)建索引。

3.可預(yù)知的用來頻繁查找的字段上創(chuàng)建索引。

6.8.44.小表可以不需要特意去創(chuàng)建索引。有主鍵就好。

6.8.5索引的注意事項(xiàng)

1.一個(gè)經(jīng)常插入更新的表不要加太多索引，因?yàn)樗饕绊懖迦牒透碌乃俣取?/p>

2.所有非聚集索引包含聚集索引鍵值，創(chuàng)建非聚集索引時(shí)不要再包含進(jìn)來。

3.如果知道索引鍵的所有值都是唯一的，那么確保把索引定義成唯一索引。唯一索引除了可以保證數(shù)

據(jù)的正確性外還可能幫助優(yōu)化器生成更高效的執(zhí)行計(jì)劃。因?yàn)樵谖ㄒ凰饕忻啃卸际俏ㄒ坏模坏?/p>

找到一行,SQLServer不必進(jìn)一步查找其他匹配的行。

4.索引不只是帶來查詢優(yōu)化，對(duì)于更新操作，索引有時(shí)候優(yōu)化查詢帶來的好處會(huì)超過索引維護(hù)的開銷。

所以索引有某些情況下會(huì)縮短整個(gè)數(shù)據(jù)更新的時(shí)間。因?yàn)橛袝r(shí)候，表掃描帶來的開銷會(huì)遠(yuǎn)大于更新

操作本身的開銷。（先查找后更新）

5.盡可能地選擇那些小數(shù)據(jù)類型的列來創(chuàng)建索引，大的索引睚值增加了索引頁面的數(shù)量，從而增加了

索引所需要的內(nèi)存和磁盤活動(dòng)數(shù)量。

6.經(jīng)常有范圍杳詢（between,>,<,>=,<=）或用來作條件i反回很多列和orderby、groupby發(fā)

生的列，可考慮建立聚集索引；（分區(qū)字段是時(shí)間類型的話，適合聚集索引）

7.非聚集索引在需要從一個(gè)大表上讀取少量的行時(shí)最有用。當(dāng)匹配返回的記錄數(shù)過多時(shí)，需要用到的

書簽查找（鍵查找）的開銷將會(huì)變得很大。所以像性別這樣的字段不要?jiǎng)?chuàng)建非聚集索引。低選擇性的

列只能配合其它字段創(chuàng)建復(fù)合非聚集索引。

8.多個(gè)字段創(chuàng)建組合索引時(shí)要盡量使關(guān)鍵查詢形成索引覆蓋其第一個(gè)列一定是使用最頻繁的列；但

包含的列不能太多，不能有大類型的字段。

9.缺乏合適的索引也是造成阻塞、死鎖的原因。

10.頻繁更新的列不適合創(chuàng)建聚集索引。

686主鍵就是聚集索引，極端錯(cuò)誤的，是對(duì)聚集索引的一種浪費(fèi)。雖

然SQLSERVER默認(rèn)是在主鍵上建立聚集索引的。顯而易見,

聚集索引的優(yōu)勢是很明顯的，而每個(gè)表中只能有一個(gè)聚集索引

的規(guī)則，這使得聚集索引變得更加珍貴。使用聚集索引的最大

好處就是能夠根據(jù)查詢要求，迅速縮小查詢范圍，避免全表掃

描。（尤其是分區(qū)表，適合時(shí)間做聚集索引）

687索引的后期維護(hù)工作

1.索引創(chuàng)建后不就是完事了的，一定要定期觀察索引在實(shí)際工作環(huán)境中的使用情況。及時(shí)阻止索

引對(duì)系統(tǒng)帶來的負(fù)面影響。總的來說應(yīng)該考慮如下幾點(diǎn)：

2.去掉使用率低的索引。

3.合理的改善索引，使索引更有效的被利用到。

4.創(chuàng)建缺失的必要的索引。

考慮索引碎片的問題.索引碎片率過大時(shí)，杳詢彳異不到優(yōu)化.

由于表上有過度地插入、修改和刪除操作，索引頁被分成多塊就形成了索引碎片，如果索引碎片嚴(yán)

重，那么掃描索引的時(shí)間就會(huì)變長，甚至導(dǎo)致索引不可用，因此數(shù)據(jù)檢索操作就慢下來了。如果碎片

小于10%~20%,碎片不太可能會(huì)成為問題，如果索引碎片在20%~40%,碎片可能成為訶題，但是

可以通過索引重組來消除索引解決，大規(guī)模的碎片（當(dāng)碎片大于40%）,可能要求索引重建。

一查看某個(gè)表的碎片情況（整理數(shù)據(jù)的碎片，是整理聚集索引的碎片）

一結(jié)果看LogicalFramentation字段

DBCCSHOWCONTIG（'[dbo].[TLog]'）WITHFAST,TABLERESULTS,ALL_IXDEXES,N0_IXF0MSGS;

6.9總之，索引的后期跟蹤是不斷持續(xù)的過程。為了搭建高性能的系統(tǒng)環(huán)境,

就必須定期有效的跟蹤索引。

6.10物理存儲(chǔ)設(shè)計(jì)

6.10.1除了重視邏輯對(duì)象的設(shè)計(jì)，還需要考慮數(shù)據(jù)庫的物理設(shè)計(jì)。在

并發(fā)要求很高、并發(fā)用戶數(shù)很多的情況下，這一設(shè)計(jì)對(duì)數(shù)據(jù)庫

的性能起到十分關(guān)鍵的作用。

6.10.2數(shù)據(jù)庫物理文件一般不要存放在C盤，因?yàn)橄到y(tǒng)重裝對(duì)C盤破

壞最大。

6.10.3日志文件另外存放

6.10.4查詢數(shù)據(jù)庫的頁，可以看到，由于頁的ID不連續(xù)，所以數(shù)據(jù)文

件內(nèi)部的讀寫是隨機(jī)的。而日志文件的讀寫是順序的，所以兩

者放在同一個(gè)硬盤上，會(huì)造成硬盤驅(qū)動(dòng)器一會(huì)隨機(jī)，一會(huì)順序,

效率會(huì)比較低。將數(shù)據(jù)文件和日志分離存儲(chǔ)在不同的物理硬盤

±o這樣的好處是確保數(shù)據(jù)的安全，避免單點(diǎn)失效。二是確保

數(shù)據(jù)庫的性能。同樣備份文件也在不同的磁盤上。

6?10.5存儲(chǔ)空間的設(shè)計(jì)

正確評(píng)估和測算數(shù)據(jù)庫的物理空間需求。因?yàn)閿?shù)據(jù)庫采用預(yù)先分配存儲(chǔ)空間的方法。存儲(chǔ)空間的分

配操作是一個(gè)非常消耗資源的操作。所以設(shè)計(jì)人員需要評(píng)估數(shù)據(jù)空間的可能增長率，將數(shù)據(jù)庫的空間增

長方式設(shè)置為恰當(dāng)好處，這樣就可以在空間和效率之間取得均衡。

1.設(shè)計(jì)要考慮的內(nèi)容有：

2.數(shù)據(jù)庫文件和日志文件初始值的設(shè)計(jì)。

3.數(shù)據(jù)庫文件和日志文件以多大的比例增長。（不要用默認(rèn)的1M或10%）要設(shè)置成按固定大小

增長，這樣就能避免一次增長太多或者太少所帶來的不必要的影響。建議對(duì)比較小白徵據(jù)庫，設(shè)

置一次增長50MB到100MB。對(duì)大的數(shù)據(jù)庫，設(shè)置一次增長200MB到800MB。

4.對(duì)于生產(chǎn)數(shù)據(jù)庫，推薦的設(shè)置是開啟數(shù)據(jù)庫自動(dòng)增長和不限制大小，以防數(shù)據(jù)庫空間用盡導(dǎo)致

應(yīng)用程序失敗。

5.在系統(tǒng)一段時(shí)間穩(wěn)定后，可以采取日志備份的機(jī)制使得數(shù)據(jù)庫日志文件大小固定下來，不再持

續(xù)增長。事務(wù)日志備份可以截?cái)嗳罩荆跈z直點(diǎn)發(fā)生時(shí)會(huì)清空日志，這樣會(huì)在已有的空間內(nèi)重新

記錄日志，而不用分配新的空間。

6.分配空間和壓縮空間都很帶來很大的資源開銷，所以盡量避免數(shù)據(jù)庫進(jìn)行這兩個(gè)操作。比如對(duì)

日志文件截?cái)嗪蟛灰褂檬湛s空間的操作，如果一定要收縮那么收縮到一個(gè)合適的值，這樣避

免日志文件重新分配空間。（不要收縮到最小空間，比如1M）

7.不要開啟數(shù)據(jù)庫的自動(dòng)關(guān)閉和自動(dòng)收縮選項(xiàng)。

7T?SQL編碼規(guī)范

7.1在設(shè)計(jì)確定的情況下，編碼的質(zhì)量幾乎決定了整個(gè)系統(tǒng)的質(zhì)量。編碼階段

首先是需要所有程序員有性能意識(shí)，也就是在實(shí)現(xiàn)功能同時(shí)有考慮性能

的思想。

7.2編寫規(guī)范的SQL語句不但利于閱讀，而且被數(shù)據(jù)庫重復(fù)使用的幾率也較

大，執(zhí)行效率相對(duì)較高，編寫的好的SQL與編寫的差的SQL在執(zhí)行性能

上可能會(huì)差幾倍甚至幾千幾萬倍，因此養(yǎng)成好的SQL編寫規(guī)范對(duì)于提高

項(xiàng)目質(zhì)量及提高開發(fā)人員自身素質(zhì)有著潛在的極大的影響。

7.3書寫基本規(guī)范

1.大小寫規(guī)則。

2.為了最大限度實(shí)現(xiàn)SQL的共享，要求書寫SQL語句時(shí)大小寫要一致，（比如保留關(guān)犍字、謂詞

和系統(tǒng)函數(shù)律大寫）這樣做的好處有兩點(diǎn)：一是為了閱讀方便。二是不統(tǒng)的語句由于寫法

不完全相同，數(shù)據(jù)庫會(huì)理解為4條不同的語句從而導(dǎo)致重復(fù)編譯，降低了性能。系統(tǒng)對(duì)象（系統(tǒng)

存儲(chǔ)過程、視圖、表，系統(tǒng)字段），按照系統(tǒng)定義的大小寫執(zhí)行（數(shù)據(jù)庫里怎么定義就怎么引用）；

數(shù)據(jù)庫對(duì)象名稱，按照實(shí)際定義的大小寫執(zhí)行（數(shù)據(jù)庫里怎么定義就怎么引用）

3.養(yǎng)成注釋的好習(xí)慣。

4.存儲(chǔ)過程、函數(shù)、視圖、觸發(fā)器等對(duì)象不僅要求創(chuàng)建時(shí)加上必要的注釋，而且在以后修改的過

程中也應(yīng)該有注釋。螃最好以英文為主，盡可能做到簡潔而描述清晰。另外表也可以加上注

釋說明。

5.有結(jié)束符。

6.每一個(gè)完整的T-SQL語句都要以分號(hào)結(jié)束。據(jù)說在以后的數(shù)據(jù)庫版本里面會(huì)強(qiáng)制要求。現(xiàn)在的

版本，在公用表達(dá)式的編寫中，就有這個(gè)限制。

7.所有的賦值語句要求變量與運(yùn)算符之間要有空格。如：v_count=v.count+1;,并保持適當(dāng)

的對(duì)齊。

8.引用對(duì)象時(shí)帶上架構(gòu)名。這也是比較推薦的寫法。默認(rèn)的架構(gòu)名為db。。在創(chuàng)建物化視圖是就

深有體會(huì).

9.以內(nèi)縮來標(biāo)示IF、WHILE.BEGINEND.TRYCACHE等程序代碼區(qū)域。

10.在SQL代碼快中盡量使用BEGIN...END語句塊，提高代碼可閱讀性。

7.4在多表連接時(shí)，盡量用表別名十字段的格式來返回列。

7.5換行規(guī)則。BEGIN/END獨(dú)占一行；FROM子句獨(dú)占一行；WHERE子

句獨(dú)占一行；GROUPBY子句獨(dú)占一行；ORDERBY子句獨(dú)占一行；

單獨(dú)的LEFTJOIN和INNERJOIN獨(dú)占一行如果一行寫不完換行時(shí),

需要確保每行邏輯完整性。

7.6使用可搜索參數(shù)（where使用原則）

建立索引后，并不是每個(gè)查詢都會(huì)使用索引，在使用索引的情況下，索引的使用效率也會(huì)有很大的

差別。只要我們?cè)诓樵冋Z句中沒有強(qiáng)制指定索引，索引的選擇和使用方法是SQLSERVER的優(yōu)化器自動(dòng)

作的選擇，而它選擇的根據(jù)是查詢語句的條件以及相關(guān)表的統(tǒng)計(jì)信息，這就要求我們?cè)趯慡QL語句的時(shí)

候盡量使得優(yōu)化器可以使用索引。

1.為了使得優(yōu)化器能高效使用索引，寫語句的時(shí)候應(yīng)該注意下面四點(diǎn)：

2.不要對(duì)索引字段進(jìn)行運(yùn)算，而要想辦法做變換。

3.不要對(duì)索引字段進(jìn)行格式轉(zhuǎn)換。

4.不要對(duì)索引字段使用函數(shù)。

5.不要對(duì)索引字段進(jìn)行多字段連接。

索引掃描或索引查找

所以在where條件語句中有時(shí)候一些不規(guī)范

的寫法會(huì)造成索引失效。右邊的寫法要優(yōu)于左

邊，因?yàn)橛疫吙赡軙?huì)使得索引，而左列的寫法

是用不上索弓1的。（同樣適用于。N條件中）

索引掃描

WHEREYEAR（OrderDate）=2001WHEREOrderDate>=‘2001-07-01,

MONTH（OrderDate）=7（對(duì)條件字段使用函數(shù)ANDOrderDate<'2001-08-01,

或用戶自定義函數(shù)）

WHEREWHEREOrderDate

DATEDIFF(day,OrderDate,GETDATE())>DATEADD(DAY,-5,GETDATE())

5

WHERELEFT(AccountName,3)='fan1WHEREAccountNameLIKE1fan%1

WHEREid+9>WHEREid>@id-9

WHERECodeLIKE'%Core%1WHERECodeLIKE'Core%1

NOTIN(SELECTIDFROM)LEFTJOINbWHEREb.IDISNULL

或

NOTEXISTS(SELECT*FROMb)

WHEREIDIN(2,3,4,5,6)WHEREID>=2ANDID<=6

WHEREFirstName+'*+LastName='fanWHEREFirstName=1fan*AND

you';LastNair.e=*you*

WHERE[Status]<>10WHERE[StAbns]<1fiAND

[Status]>10

NOTIN、LEFTJOIN.NOTEXISTS和IN、INNERJOIN、EXISTS的效率問題要具體情況具體分

析。一般情況下推薦使用相關(guān)子查詢（EXISTS）和連接的方式。

7.7SQLServer從左到右處理表，這個(gè)在技術(shù)內(nèi)幕上有。而where語句中

最能快速篩選數(shù)據(jù)的列應(yīng)該放在最前面，也就是最接近where子句的地

方。但在SQLSERVER2005后來的版本中，優(yōu)化器會(huì)幫你自動(dòng)優(yōu)化的。

7.8少用觸發(fā)器和禁用游標(biāo)

觸發(fā)器觸發(fā)器在時(shí)間久遠(yuǎn)后不易維護(hù),觸發(fā)器不會(huì)立即讓開發(fā)人員看到。而且觸發(fā)

器內(nèi)容太過復(fù)雜，還會(huì)存在潛在的性能瓶頸。所以我們統(tǒng)一規(guī)定不允許使用觸發(fā)

器，應(yīng)使用其它辦法來代替觸發(fā)器。對(duì)之前已經(jīng)存在的觸發(fā)器也應(yīng)該抽時(shí)間去替

換它。項(xiàng)目負(fù)責(zé)人還需要檢查是否產(chǎn)生了新的觸發(fā)器并及時(shí)糾正。

游標(biāo)SQLServer適合在數(shù)據(jù)集（多行）上進(jìn)行操作游標(biāo)是把結(jié)果集放在服務(wù)器

內(nèi)存，并通過循環(huán)一條一條處理記錄，對(duì)數(shù)據(jù)庫資源（特別是內(nèi)存和鎖資源）的

消耗是非常大的。

7.9聯(lián)合查詢盡可能使用UNIONALL

7.10UNION操作依次執(zhí)行所有的SELECT語句，將所有的結(jié)果集合并為一個(gè)

結(jié)果集。將對(duì)結(jié)果集進(jìn)行排序，并過濾掉重復(fù)的記錄。可見聯(lián)合查詢的效

率很低的，除非在必要的情況下才使用。如果允許結(jié)果集存在重復(fù)，或預(yù)

知結(jié)果集根本不可能重復(fù)時(shí)一定要用UNIONALL來代替。

7?11盡可能避免的地方

如果SELECT語句中查詢的字段很多，則使用該關(guān)鍵字段反而會(huì)大

下面這些操作在使

大降低查詢效率。因?yàn)椴樵冏侄魏芏鄷r(shí)，如果使用篩選重復(fù)關(guān)鍵字，數(shù)

據(jù)庫引擎需要花費(fèi)大量的時(shí)間對(duì)所有字段進(jìn)行比較，過濾掉重復(fù)的記

用前，可以重新思

錄，因此影響了查詢效率。

考下業(yè)務(wù)和檢查一

下邏輯，看是否可

以避免。

DISTINCT關(guān)鍵字

OrderByOrderBy等語句盡量是杳詢結(jié)果需要才使用，因?yàn)樘Χ夹枰鲱~

外的計(jì)算。不管你使用TOP返回少量記錄，但OrderBy都會(huì)事先排完

序的。

嵌套視圖嵌套視圖是當(dāng)一個(gè)視圖調(diào)用另一個(gè)視圖時(shí)，另一個(gè)視圖調(diào)用更多的

視圖.這可能導(dǎo)致非常容易混淆的代碼，因?yàn)橐晥D掩蓋了被執(zhí)行的操

作。雖然查詢可能非常簡單，執(zhí)行計(jì)劃和隨后SQL引擎的操作可能非

常復(fù)雜并且代價(jià)很高。同樣，嵌套的用戶自定義函數(shù)也是如此。

嵌套自定義函數(shù)注意表值函數(shù)分內(nèi)聯(lián)表值函數(shù)和多語句表值函數(shù)。多語句表值函數(shù)

是用表變量返回的，對(duì)此用執(zhí)行計(jì)劃查看時(shí)，優(yōu)化器不能夠很好地估

計(jì)執(zhí)行用戶定義函數(shù)的成本(不適合返回大量數(shù)據(jù)行)。所以必須引起

注意，有時(shí)候引用的自定義函數(shù)可以隱藏性能問題，所以應(yīng)該分析內(nèi)

部的語句。

7.12避免返回和使用多余的數(shù)據(jù)

1.返回?cái)?shù)據(jù)到客戶端至少需要數(shù)據(jù)庫提取數(shù)據(jù)、網(wǎng)絡(luò)傳輸數(shù)據(jù)、客戶端接收數(shù)據(jù)以及客戶端處理

數(shù)據(jù)等環(huán)節(jié)，如果返回不需要的數(shù)據(jù)，就會(huì)增加服務(wù)器、網(wǎng)絡(luò)和客戶端的壓力，其害處是顯而

易見的，避免這類事件需要注意：

比如可能只要用到TProduct表就可以了,但卻用VProduct

橫向來看，不要寫

視圖，而VProduct視圖可能存在更多的表連接，甚至帶來了不

必要的性能問題。

SELECT*的語句，而是選

擇你需要的字段。

縱向來看，合理寫

WHERE子句，不要寫沒有

WHERE的SQL語句。

通用視圖帶來的干擾

返回多余的列返回多余的列可能會(huì)造成書簽查找操作，本來有時(shí)候非聚

集索引能解決的，還額外的使用了書簽查找。更不要允許出現(xiàn)

SELECT*這樣的語句。

但在相關(guān)子查詢中使用EXISTS(SELECT*)可以放心使用

因?yàn)镋XISTS只關(guān)心行是否存在，不關(guān)心特定屬性，優(yōu)化器

將會(huì)忽略子查詢中的SELECT列表。

但在相關(guān)子查詢中使用EXISTS(SELECT*)可以放心使用

因?yàn)镋XISTS只關(guān)心行是否存在，不關(guān)心特定屬性，優(yōu)化器

將會(huì)忽略子查詢中的SELECT列表。

SETNOCOUNTON存儲(chǔ)過程內(nèi)部用SETNOCOUNTON;否則每次執(zhí)行完就

會(huì)向客戶端發(fā)送消息，禁用它們能夠減少網(wǎng)絡(luò)流量。

7.13操作符優(yōu)化

1.IN和EXISTS性能有外表和內(nèi)表區(qū)分的，但是在大數(shù)據(jù)量的表中推薦用EXISTS代替IN。

2.NOTIN不走索引的是絕對(duì)不能用的，可以用NOTEXISTS代替。

3.ISNULL或ISNOTNULL操作

4.索引是不索引空值的，所以這樣的操作不能使用索弓I,可以用其他的辦法處理，例如：數(shù)字類型,

判斷大于0,字符串類矍設(shè)置一個(gè)默認(rèn)值，判斷是否等于默認(rèn)值即可，例如>〃

7.14<>操作符（不等于）不等于操作符是永遠(yuǎn)不會(huì)用到索引的，因此對(duì)它

的處理只會(huì)產(chǎn)生全表掃描。用其它相同功能的操作運(yùn)算代替，如av>0

改為a>OORa<0同樣av>''改為a>"ORa<"

7.15高版本的數(shù)據(jù)庫引擎可能會(huì)對(duì)上面的問題進(jìn)行自動(dòng)優(yōu)化，但養(yǎng)成好的習(xí)

慣也是必要的。

7.16數(shù)據(jù)庫事務(wù)處理原則

1.事務(wù)過程中可能包含查詢語句和修改語句，對(duì)于查詢語句所申請(qǐng)的共享鎖會(huì)在查詢結(jié)束時(shí)釋放,

而對(duì)于修改語句申請(qǐng)的獨(dú)占鎖會(huì)持續(xù)到事務(wù)結(jié)束。所以你需要認(rèn)真規(guī)劃事務(wù)：

2.保持事務(wù)范圍盡可能地小。不必要的語句盡量要拿到事務(wù)之外。

3.盡早提交事務(wù)。所以事務(wù)涉及到的SQL語句不能過于復(fù)雜。

4.避免事務(wù)不能結(jié)束。

使用SETXACT_ABORTON確保事務(wù)出現(xiàn)錯(cuò)誤時(shí)中止或回滾。

5.消除讀寫阻塞。比如使用臟讀（表名后加WITH（NOLOCK））e（減少鎖開銷）如果不是重要的、

特別敏感的數(shù)據(jù)，允許駐讀可以避免一定程度的阻塞，加快查詢速度。

6.事務(wù)操作過程盡量要按同一順序訪問表對(duì)象。

7.17提高事務(wù)中每個(gè)語句的效率，利用索引和其他方法提高每個(gè)語句的效率

可以有效地減少整個(gè)事務(wù)的執(zhí)行時(shí)間。

7.18盡量不要指定鎖類型和索引，SQLSERVER允許我們自己指定語句使用

的鎖類型和索引，但是一般情況下,SQLSERVER優(yōu)化器選擇的鎖類型和

索引是在當(dāng)前數(shù)據(jù)量和查詢條件下是最優(yōu)的，我們指定的可能只是在目

前情況下更有，但是數(shù)據(jù)量和數(shù)據(jù)分布在將來是會(huì)變化的。

7.19最少次數(shù)的訪問表

盡量少做重復(fù)的工作，最少次數(shù)的訪問表。

如果可以只訪問一次表就沒有必要再次訪問表。有的是存儲(chǔ)過程內(nèi)部語句太多，寫在后面沒有

留意的問題。所以需要審查自己寫的存儲(chǔ)過程。

UPDATEdbo.TEMPLOYEESETFNAME=,HAIWER*WHEREEMP_ID='VPA30890F';

UPDATEdbo.TEMPLOYEESETLNAME=*YANG*WHEREEMP_ID='VPA30890F';

1.使用公用表達(dá)式CTE,可以多次引用，從而減少基礎(chǔ)表的訪問次數(shù)。

2.使用0?ROWCOUNT判斷影響的表行數(shù)從而避免表多次返問。

7.20避免隱含的數(shù)據(jù)類型轉(zhuǎn)換

—Code本來是NVARCHAR(36)類型

DECLARE@codeVARCHAR(36);

SET?code='0D32C649-A584-4629-8EE3-DDF26A61F9C1,;

SELECT*FROMdbo.TTablelWHEREID=?code;

在執(zhí)行計(jì)劃中看到，導(dǎo)致需要額外的操作對(duì)值進(jìn)行轉(zhuǎn)換之后才能用于比較。

在Unicode字符前面使用N前綴避免引起數(shù)據(jù)的不一致。