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個左右的不同州名的縮寫值，可以使用镞索引。
