資料庫設計
實現sql server資料庫的優化,首先要有乙個好的資料庫設計方案。在實際工作中,許多sql server方案往往是由於資料庫設計得不好導致效能很差。實現良好的資料庫設計必須考慮這些問題:
1. 邏輯資料庫規範化問題
一般來說,邏輯資料庫設計會滿足規範化的前3級標準:
第1規範:沒有重複的組或多值的列;
第2規範: 每個非關鍵字段必須依賴於主關鍵字,不能依賴於乙個組合式主關鍵字的某些組成部分;
第3規範: 乙個非關鍵字段不能依賴於另乙個非關鍵字段。
遵守這些規則的資料庫設計會產生較少的列和更多的表,因而也就減少了資料冗餘,也減少了用於儲存資料的頁。
2. 生成物理資料庫
要想正確選擇基本物理實現策略,必須了解和利用好資料庫訪問格式和硬體資源的操作特點,特別是記憶體和磁碟子系統i/o。以下是一些常用技巧:
與每個表列相關的資料型別應該反映資料所需的最小儲存空間,特別是對於被索引的列更是如此。比如能使用**allint型別就不要用integer型別,這樣索引字段可以被更快地讀取,而且可以在乙個資料頁上放置更多的資料行,因而也就減少了i/o操作。
把乙個表放在某個物理裝置上,再通過sql server的段把它的不分簇索引放在乙個不同的物理裝置上,這樣能提高效能。尤其是系統採用了多個智慧型磁碟控制器和資料分離技術的情況下,這樣做的好處更加明顯。
用sql server段把乙個頻繁使用的大表分割開,並放在多個單獨的智慧型磁碟控制器的資料庫裝置上,這樣也可以提高效能。因為有多個磁頭在查詢,所以資料分離也能提高效能。
用sql server段把文字或影象列的資料存放在乙個單獨的物理裝置上可以提高效能。乙個專用的智慧型的控制器能進一步提高效能。
應用系統設計
在應用系統的設計中,要著重考慮以下幾點:
1.合理使用索引
索引是資料庫中重要的資料結構,它的根本目的就是提高查詢效率。索引的使用要恰到好處,其使用原則如下:
在經常進行連線,但是沒有指定為外來鍵的列上建立索引,而不經常連線的字段則由優化器自動生成索引;在頻繁進行排序或分組(即進行group by或order by操作)的列上建立索引;在條件表示式中經常用到的不同值較多的列上建立索引,在不同值少的列上不要建立索引。比如在雇員表的「性別」列上只有「男」與「女」兩個不同值,因此就無必要建立索引。如果建立索引不但不會提高查詢效率,反而會嚴重降低更新速度。 如果待排序的列有多個,可以在這些列上建立復合索引。
2. 避免或簡化排序
應當盡量簡化或避免對大型表進行重複的排序。當能夠利用索引自動以適當的次序產生輸出時,優化器就避免了排序這個步驟。為了避免不必要的排序,就要正確地增建索引,合理地合併資料庫表(儘管有時可能影響表的規範化,但相對於效率的提高是值得的)。如果排序不可避免,那麼應當試圖簡化它,如縮小排序的列的範圍等。
3.消除對大型錶行資料的順序訪問
在巢狀查詢中,表的順序訪問對查詢效率可能產生致命的影響。我們有時可以使用並集來避免順序訪問。儘管也許在所有的檢查列上都有索引,但某些形式的where子句會強迫優化器使用順序訪問,這一點也應注意。
4. 避免相關子查詢
如果乙個列同時在主查詢和where子句中出現,很可能當主查詢中的列值改變之後,子查詢必須重新查詢一次。而且查詢巢狀層次越多,效率越低,因此應當盡量避免子查詢。如果子查詢不可避免,那麼要在子查詢中過濾掉盡可能多的行。
5.避免困難的正規表示式
mathes和like關鍵字支援萬用字元匹配,但這種匹配特別耗時。例如:select * from customer where zipcode like 「98_ _ _」,即使在zipcode欄位上已建立了索引,在這種情況下也還是採用順序掃瞄的方式。如果把語句改為:select * from customer where zipcode >「98000」,在執行查詢時就會利用索引來查詢,顯然會大大提高速度。
6.使用臨時表加速查詢
把錶的乙個子集進行排序並建立臨時表,有時能加速查詢。它有助於避免多重排序操作,而且在其他方面還能簡化優化器的工作。臨時表中的行要比主表中的行少,而且物理順序就是所要求的順序,減少了磁碟i/o,所以查詢工作量可以得到大幅減少。但要注意,臨時表建立後不會反映主表的修改。在主表中資料頻繁修改的情況下,注意不要丟失資料。
作業系統相關優化
作業系統效能的好壞直接影響資料庫的使用效能,如果作業系統存在問題,如cpu過載、過度記憶體交換、磁碟i/o瓶頸等,在這種情況下,單純進行資料庫內部效能調整是不會改善系統效能的。我們可以通過windows nt的系統監視器(system monitor)來監控各種裝置,發現效能瓶頸。
cpu 一種常見的效能問題就是缺乏處理能力。系統的處理能力是由系統的cpu數量、型別和速度決定的。如果系統沒有足夠的cpu處理能力,它就不能足夠快地處理事務以滿足需要。我們可以使用system monitor確定cpu的使用率,如果以75%或更高的速率長時間執行,就可能碰到了cpu瓶頸問題,這時應該公升級cpu。但是公升級前必須監視系統的其他特性,如果是因為sql語句效率非常低,優化語句就有助於解決較低的cpu利用率。而當確定需要更強的處理能力,可以新增cpu或者用更快的cpu 替換。
記憶體 sql server可使用的記憶體量是sql server效能最關鍵因素之一。而記憶體同i/o子系統的關係也是乙個非常重要的因素。例如,在i/o操作頻繁的系統中,sql server用來快取資料的可用記憶體越多,必須執行的物理i/o也就越少。這是因為資料將從資料快取中讀取而不是從磁碟讀取。同樣,記憶體量的不足會引起明顯的磁碟讀寫瓶頸,因為系統快取能力不足會引起更多的物理磁碟i/o。
可以利用system monitor檢查sql server的buffer cache hit ratio計數器,如果命中率經常低於90%,就應該新增更多的記憶體。
i/o子系統 由i/o子系統發生的瓶頸問題是資料庫系統可能遇到的最常見的同硬體有關的問題。配置很差的i/o子系統引起效能問題的嚴重程度僅次於編寫很差的sql語句。i/o子系統問題是這樣產生的,乙個磁碟驅動器能夠執行的i/o操作是有限的,一般乙個普通的磁碟驅動器每秒只能處理85次i/o操作,如果磁碟驅動器超載,到這些磁碟驅動器的i/o操作就要排隊,sql的i/o延遲將很長。這可能會使鎖持續的時間更長,或者使執行緒在等待資源的過程中保持空閒狀態,其結果就是整個系統的效能受到影響。
解決i/o子系統有關的問題也許是最容易的,多數情況下,增加磁碟驅動器就可以解決這個效能問題。
當然,影響效能的因素很多,而應用又各不相同,找出乙個通用的優化方案是很困難的,只能是在系統開發和維護的過程中針對執行的具體情況,不斷加以調整。
[**]
資料庫效能優化
1 系統設計 1 縱向 橫向分割表,減少表的尺寸 縱向 欄位多。按業務主題分割。根據頁大小。橫向 資料多。按條件分割表。eg 按年儲存表,歷史資料表和當期資料更新表。2 將資料處理交給db,編寫儲存過程 1 減少網路的開銷 2 儲存過程是編譯 優化過,速度快。3 唯讀查詢操作優化方法 1 資料量小的...
資料庫效能優化
最近要寫一些關於企業級應用的優化內容的東西,就先從資料庫優化入手吧,在這裡先記錄一下。作為一名有資料庫教育背景的工作人員,我著重從db的角度介紹一下,我認為的db優化方式。首先,撇開經濟商業用處不談,db效能優化的原則主要是,通過盡可能少的磁碟訪問獲得所需的資料。一般而言,資料的是優化可以從三方面分...
資料庫效能優化
1.在join表的時候使用相當型別的例,並將其索引 2.千萬不要 order by rand 3.使用 enum 而不是 varchar 4.永遠為每張表設定乙個id 5.從 procedure analyse 取得建議 6.盡可能的使用 not null 7.固定長度的表會更快 myisam 適合...