影響SqlServer效能的因素分析與解決方案

1> 電腦硬體
當您懷疑電腦硬體是影響SQL Server運行效能的主要原因時，可以通過SQL Server Performance Monitor監視相應硬體的負載，以便證實您的猜測並找出系統瓶頸。

2> 作業系統

3> Sql Server 應用程式

1 邏輯資料庫和表的設計

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

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

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

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

C:更窄更緊湊的索引

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

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

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

2 索引的設計

檢查你的查詢語句的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語句將會使效能下降一些。實驗表明，不要在一個單表上用大量的索引，不要在共用的列上（指在多表中用了參考約束）使用重疊的索引。

還可以使用工具：
Profiler/Index Tuning Wizard 組合在涉及許多表和許多查詢的實際資料庫伺服器環境中功能非常強大。當資料庫進行中典型查詢時，請使用 Profiler 記錄 .trc 檔案。然後將 .trc 檔案裝載到 Index Tuning Wizard，以確定是否建立了正確的索引。根據 Index Tuning Wizard 中的提示自動產生並調度索引建立作業以便在非尖峰時刻運行。定期運行 Profiler/Index Tuning Wizard（比如每周）以查看資料庫伺服器中所執行的查詢是否有較大改動，如果是，則可能需要不同的索引。定期使用 Profiler/Index Tuning Wizard 有助於資料庫管理員在查詢工作負載改變以及資料庫大小隨著時間而增加的同時，保持 SQL Server 以最佳狀態運行。

比較的解決方案是：設計時儘可能的設計好相關索引，利用工具作為檢驗的手段。

3 查詢語句的設計
(還是注意where子句中的列所在的索引.)

4 分區視圖

4> 客戶應用程式

... to be continued