網(LieHuo.Net)教程 近期因工作需要,希望比較全面的總結下SQL SERVER數據庫性能優化相關的注意事項,在網上搜索了一下,發現很多文章,有的都列出了上百條,但是仔細看發現,有很多似是而非或者過時(可能對SQL SERVER6.5以前的版本或者ORACLE是適用的)的信息,只好自己根據以前的經驗和測試結果進行總結了。
我始終認為,一個系統的性能的提高,不單單是試運行或者維護階段的性能調優的任務,也不單單是開發階段的事情,而是在整個軟件生命周期都需要注意,進行有效工作才能達到的。所以我希望按照軟件生命周期的不同階段來總結數據庫性能優化相關的注意事項。
一、 分析階段
一般來說,在系統分析階段往往有太多需要關注的地方,系統各種功能性、可用性、可靠性、安全性需求往往吸引了我們大部分的注意力,但是,我們必須注意,性能是很重要的非功能性需求,必須根據系統的特點確定其實時性需求、響應時間的需求、硬件的配置等。最好能有各種需求的量化的指標。
另一方面,在分析階段應該根據各種需求區分出系統的類型,大的方面,區分是OLTP(聯機事務處理系統)和OLAP(聯機分析處理系統)。
二、 設計階段
設計階段可以說是以后系統性能的關鍵階段,在這個階段,有一個關系到以后幾乎所有性能調優的過程—數據庫設計。
在數據庫設計完成后,可以進行初步的索引設計,好的索引設計可以指導編碼階段寫出高效率的代碼,為整個系統的性能打下良好的基礎。
以下是性能要求設計階段需要注意的:
1、 數據庫邏輯設計的規范化
數據庫邏輯設計的規范化就是我們一般所說的范式,我們可以這樣來簡單理解范式:
第1規范:沒有重復的組或多值的列,這是數據庫設計的最低要求。
第2規范: 每個非關鍵字段必須依賴于主關鍵字,不能依賴于一個組合式主關鍵字的某些組成部分。消除部分依賴,大部分情況下,數據庫設計都應該達到第二范式。
第3規范: 一個非關鍵字段不能依賴于另一個非關鍵字段。消除傳遞依賴,達到第三范式應該是系統中大部分表的要求,除非一些特殊作用的表。
更高的范式要求這里就不再作介紹了,個人認為,如果全部達到第二范式,大部分達到第三范式,系統會產生較少的列和較多的表,因而減少了數據冗余,也利于性能的提高。
2、 合理的冗余
完全按照規范化設計的系統幾乎是不可能的,除非系統特別的小,在規范化設計后,有計劃地加入冗余是必要的。
冗余可以是冗余數據庫、冗余表或者冗余字段,不同粒度的冗余可以起到不同的作用。
冗余可以是為了編程方便而增加,也可以是為了性能的提高而增加。從性能角度來說,冗余數據庫可以分散數據庫壓力,冗余表可以分散數據量大的表的并發壓力,也可以加快特殊查詢的速度,冗余字段可以有效減少數據庫表的連接,提高效率。
3、 主鍵的設計
主鍵是必要的,SQL SERVER的主鍵同時是一個唯一索引,而且在實際應用中,我們往往選擇最小的鍵組合作為主鍵,所以主鍵往往適合作為表的聚集索引。聚集索引對查詢的影響是比較大的,這個在下面索引的敘述。
在有多個鍵的表,主鍵的選擇也比較重要,一般選擇總的長度小的鍵,小的鍵的比較速度快,同時小的鍵可以使主鍵的B樹結構的層次更少。
主鍵的選擇還要注意組合主鍵的字段次序,對于組合主鍵來說,不同的字段次序的主鍵的性能差別可能會很大,一般應該選擇重復率低、單獨或者組合查詢可能性大的字段放在前面。
4、 外鍵的設計
外鍵作為數據庫對象,很多人認為麻煩而不用,實際上,外鍵在大部分情況下是很有用的,理由是:
外鍵是最高效的一致性維護方法,數據庫的一致性要求,依次可以用外鍵、CHECK約束、規則約束、觸發器、客戶端程序,一般認為,離數據越近的方法效率越高。
謹慎使用級聯刪除和級聯更新,級聯刪除和級聯更新作為SQL SERVER 2000當年的新功能,在2005作了保留,應該有其可用之處。我這里說的謹慎,是因為級聯刪除和級聯更新有些突破了傳統的關于外鍵的定義,功能有點太過強大,使用前必須確定自己已經把握好其功能范圍,否則,級聯刪除和級聯更新可能讓你的數據莫名其妙的被修改或者丟失。從性能看級聯刪除和級聯更新是比其他方法更高效的方法。
5、 字段的設計
字段是數據庫最基本的單位,其設計對性能的影響是很大的。需要注意如下:
A、數據類型盡量用數字型,數字型的比較比字符型的快很多。
B、 數據類型盡量小,這里的盡量小是指在滿足可以預見的未來需求的前提下的。
C、 盡量不要允許NULL,除非必要,可以用NOT NULL+DEFAULT代替。
D、少用TEXT和IMAGE,二進制字段的讀寫是比較慢的,而且,讀取的方法也不多,大部分情況下最好不用。