數據庫性能優化的方法(轉)

本博客不再更新,更多精彩內容請訪問我的獨立博客

如今,互聯網上關於數據庫優化方面的文章很多,但是有的寫的似是而非,有的不切實際,對一個數據庫來說,只能做到更優,不可能最優,並且由於實際需求不同,優化方案還是有所差異的,根據實際需要關心的方面(速度、存儲空間、可維護性、可拓展性)來優化數據庫,而這些方面往往又是相互矛盾的。

數據庫性能優化的方法-馬海祥博客

一個系統的性能的提高,不單單是試運行或者維護階段的性能調優,也不單單是開發階段的事情,而是在整個軟件生命週期都需要注意,所以,我按照軟件生命週期的不同階段來總結數據庫性能優化相關的方法及注意事項。

一、爲什麼要優化數據庫?

數據庫的應用程序優化通常可分爲兩個方面:源代碼和SQL語句。

由於涉及到對程序邏輯的改變,源代碼的優化在時間成本和風險上代價很高,而對數據庫系統性能的提升收效有限,那麼,我們爲什麼要優化SQL語句呢?

1、SQL語句是對數據庫進行操作的惟一途徑,對數據庫系統的性能起着決定性的作用。

2、SQL語句消耗了70%至90%的數據庫資源。

3、SQL語句獨立於程序設計邏輯,對SQL語句進行優化不會影響程序邏輯。

4、SQL語句有不同的寫法,在性能上的差異非常大。

5、SQL語句易學,但難精通。

優化SQL語句的傳統方法是通過手工重寫來對SQL語句進行優化,DBA或資深程序員通過對SQL語句執行計劃的分析,依靠經驗,嘗試重寫SQL語句,然後對結果和性能進行比較,以試圖找到性能較佳的SQL語句。

這種傳統上的作法無法找出SQL語句的所有可能寫法,且依賴於人的經驗,非常耗費時間。

二、分析階段

一般來說,在系統分析階段往往有太多需要關注的地方,系統各種功能性、可用性、可靠性、安全性需求往往吸引了我們大部分的注意力。

但是,馬海祥必須提醒大家要注意一點,性能是很重要的非功能性需求,必須根據系統的特點確定其實時性需求、響應時間的需求、硬件的配置等,最好能有各種需求的量化的指標。

另一方面,在分析階段應該根據各種需求區分出系統的類型,大的方面,區分是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,二進制字段的讀寫是比較慢的,而且,讀取的方法也不多,大部分情況下最好不用。

E、自增字段要慎用,不利於數據遷移。

6、數據庫物理存儲和環境的設計

在設計階段,可以對數據庫的物理存儲、操作系統環境、網絡環境進行必要的設計,使得我們的系統在將來能適應比較多的用戶併發和比較大的數據量。

這裏需要注意文件組的作用,適用文件組可以有效把I/O操作分散到不同的物理硬盤,提高併發能力。

7、系統設計

整個系統的設計特別是系統結構設計對性能是有很大影響的,對於一般的OLTP系統,可以選擇C/S結構、三層的C/S結構等,不同的系統結構其性能的關鍵也有所不同。

系統設計階段應該歸納一些業務邏輯放在數據庫編程實現,數據庫編程包括數據庫存儲過程、觸發器和函數,用數據庫編程實現業務邏輯的好處是減少網絡流量並可更充分利用數據庫的預編譯和緩存功能。

8、索引的設計

在設計階段,可以根據功能和性能的需求進行初步的索引設計,這裏需要根據預計的數據量和查詢來設計索引,可能與將來實際使用的時候會有所區別。

關於索引的選擇,馬海祥提醒大家要注意以下幾點:

A、根據數據量決定哪些表需要增加索引,數據量小的可以只有主鍵。

B、根據使用頻率決定哪些字段需要建立索引,選擇經常作爲連接條件、篩選條件、聚合查詢、排序的字段作爲索引的候選字段。

C、把經常一起出現的字段組合在一起,組成組合索引,組合索引的字段順序與主鍵一樣,也需要把最常用的字段放在前面,把重複率低的字段放在前面。

D、一個表不要加太多索引,因爲索引影響插入和更新的速度。


本帖轉自:http://www.mahaixiang.cn/znseo/820.html

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章