影響SQL server效能的關鍵三個方面

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

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

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

B:由於多表，所以多鏃的索引成為可能

C:更窄更緊湊的索引

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

E:更少的空值和更少的多餘值，增加了資料庫的緊湊性

由於標準化，所以會增加了在擷取資料時參考資料表的數目和其間的串連關係的複雜性。太多的表和複雜的串連關係會降低伺服器的效能，因此在這兩者之間需要綜合考慮。定義具有相關關係的主鍵和外來鍵時應該注意的事項主要是：用於串連多表的主鍵和參考的鍵要有相同的資料類型。

二、索引的設計

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