影響SQL Server效能的關鍵

2021-08-22 09:22:21 字數 2813 閱讀 4211

1 邏輯資料庫和表的設計

資料庫的邏輯設計、包括表與表之間的關係是優化關係型資料庫效能的核心。乙個好的邏輯資料庫設計可以為優化資料庫和應用程式打下良好的基礎。

標準化的資料庫邏輯設計包括用多的、有相互關係的窄表來代替很多列的長資料表。下面是一些使用標準化表的一些好處。

a:由於表窄,因此可以使排序和建立索引更為迅速

b:由於多表,所以多鏃的索引成為可能

c:更窄更緊湊的索引

d:每個表中可以有少一些的索引,因此可以提高insert update delete等的速度,因為這些操作在索引多的情況下會對系統效能產生很大的影響

e:更少的空值和更少的多餘值,增加了資料庫的緊湊性由於標準化,所以會增加了在獲取資料時引用表的數目和其間的連線關係的複雜性。太多的表和複雜的連線關係會降低伺服器的效能,因此在這兩者之間需要綜合考慮。

定義具有相關關係的主鍵和外來鍵時應該注意的事項主要是:用於連線多表的主鍵和參考的鍵要有相同的資料型別。

2 索引的設計

a:盡量避免表掃瞄

檢查你的查詢語句的where子句,因為這是優化器重要關注的地方。包含在where裡面的每一列(column)都是可能的侯選索引,為能達到最優的效能,考慮在下面給出的例子:對於在where子句中給出了column1這個列。

下面的兩個條件可以提高索引的優化查詢效能!

第一:在表中的column1列上有乙個單索引

第二:在表中有多索引,但是column1是第乙個索引的列

避免定義多索引而column1是第二個或後面的索引,這樣的索引不能優化伺服器效能

例如:下面的例子用了pubs資料庫。

select au_id, au_lname, au_fname from authors

where au_lname = 』white』

按下面幾個列上建立的索引將會是對優化器有用的索引

?au_lname

?au_lname, au_fname

而在下面幾個列上建立的索引將不會對優化器起到好的作用

?au_address

?au_fname, au_lname

考慮使用窄的索引在乙個或兩個列上,窄索引比多索引和復合索引更能有效。用窄的索引,在每一頁上

將會有更多的行和更少的索引級別(相對與多索引和復合索引而言),這將推進系統效能。

對於多列索引,sql server維持乙個在所有列的索引上的密度統計(用於聯合)和在第乙個索引上的

histogram(柱狀圖)統計。根據統計結果,如果在復合索引上的第乙個索引很少被選擇使用,那麼優化器對很多查詢請求將不會使用索引。

有用的索引會提高select語句的效能,包括insert,uodate,delete。

但是,由於改變乙個表的內容,將會影響索引。每乙個insert,update,delete語句將會使效能下降一些。實驗表明,不要在乙個單錶上用大量的索引,不要在共享的列上(指在多表中用了參考約束)使用重疊的索引。

在某一列上檢查唯一的資料的個數,比較它與表中資料的行數做乙個比較。這就是資料的選擇性,這比較結果將會幫助你決定是否將某一列作為侯選的索引列,如果需要,建哪一種索引。你可以用下面的查詢語句返回某一列的不同值的數目。

select count(distinct cloumn_name) from table_name

假設column_name是乙個10000行的表,則看column_name返回值來決定是否應該使用,及應該使用什麼索引。

unique values index

5000 nonclustered index

20 clustered index

3 no index

鏃索引和非鏃索引的選擇

<1:>鏃索引是行的物理順序和索引的順序是一致的。頁級,低層等索引的各個級別上都包含實際的資料頁。乙個表只能是有乙個鏃索引。由於update,delete語句要求相對多一些的讀操作,因此鏃索引常常能加速這樣的操作。在至少有乙個索引的表中,你應該有乙個鏃索引。

在下面的幾個情況下,你可以考慮用鏃索引:

例如: 某列包括的不同值的個數是有限的(但是不是極少的)

顧客表的州名列有50個左右的不同州名的縮寫值,可以使用鏃索引。

例如: 對返回一定範圍內值的列可以使用鏃索引,比如用between,>,>=,<,<=等等來對列進行操作的列上。

select * from sales where ord_date between 』5/1/93』 and 』6/1/93』

例如: 對查詢時返回大量結果的列可以使用鏃索引。

select * from phonebook where last_name = 』smith』

當有大量的行正在被插入表中時,要避免在本表乙個自然增長(例如,identity列)的列上建立鏃索引。如果你建立了鏃的索引,那麼insert的效能就會大大降低。因為每乙個插入的行必須到表的最後,表的最後乙個資料頁。

當乙個資料正在被插入(這時這個資料頁是被鎖定的),所有的其他插入行必須等待直到當前的插入已經結束。

乙個索引的葉級頁中包括實際的資料頁,並且在硬碟上的資料頁的次序是跟鏃索引的邏輯次序一樣的。

<2:>乙個非鏃的索引就是行的物理次序與索引的次序是不同的。乙個非鏃索引的葉級包含了指向行資料頁的指標。

在乙個表中可以有多個非鏃索引,你可以在以下幾個情況下考慮使用非鏃索引。

在有很多不同值的列上可以考慮使用非鏃索引

例如:乙個part_id列在乙個part表中

select * from employee where emp_id = 』pcm9809f』

查詢語句中用order by 子句的列上可以考慮使用鏃索引

3 查詢語句的設計

try catch 的效能影響

現象 大量try.catch.newtonsoft.json序列化速度明顯降低 9000ms 250ms 疑問 大量try.catch.影響效能?主要效能消耗在於跳轉到catch塊?準則 不要將try.catch.用於處理 邏輯跳轉,僅用於常規異常處理 不要濫用try.catch.總結 try.ca...

SQL Server 獲得影響行數

rowcount 返回受上一語句影響的行數。語法 rowcount 返回型別 integer 注釋 任何不返回行的語句將這一變數設定為 0 如 if 語句。示例 下面的示例執行 update 語句並用 rowcount 來檢測是否有發生更改的行。update authors set au lname...

影響hashMap效能的因素

首 先算得key得hashcode值,然後跟陣列的長度 1做一次 與 運算 看上去很簡單,其實比較有玄機。比如陣列的長度是2的4次方,那麼hashcode就會和2的4次方 1做 與 運算。很多人都有這個疑問,為什麼hashmap的陣列初始化大小都是2的次方大小時,hashmap 的效率最高,我以2的...