六、有關索引的幾個問題
問題1，是否值得在identity字段上建立聚集索引。答案取決於identity 字段如何在語句中使用。如果你經常根據該字段搜索返回很少的行，那麼在其上建立索引是值得的。反之如果identity字段根本很少在語句中使用，那麼就不應該對其建立任何索引。
問題2，一個表應該建立多少索引合適。如果表的80％以上的語句都是讀操作，那麼索引可以多些。但是不要太多。特別是不要對那些更新頻繁的表其建立很多的索引。很少表有超過5個以上的索引。過多的索引不但增加其佔用的磁盤空間，也增加了SQL Server 維護索引的開銷。
問題4：爲什麼SQL Server 在執行計劃中沒有使用你認爲應該使用的索引？原因是多樣的。一種原因是該語句返回的結果超過了表的20％數據，使得SQL Server 認爲scan比seek更有效。
另一種原因可能是表字段的statistics過期了，不能準確反映數據的分佈情況。你可以使用命令UPDATE STATISTICS tablename with FULLSCAN來更新它。只有同步的準確的statistics才能保證SQL Server 產生正確的執行計劃。過時的老的statistics常會導致SQL Server生成不夠優化的甚至愚蠢的執行計劃。所以如果你的表頻繁更新，而你又覺得和之相關的SQL語句運行緩慢，不妨試試UPDATE STATISTIC with FULLSCAN 語句。
你甚至可以使用Index hint比較不同索引的性能差異。比如對上面script 4提到的兩個索引，可以這樣比較，
select 學生姓名, 入學時間 from tbl1 with (index= idx_年齡入學時間)
where ……
或者：
select 學生姓名, 入學時間 from tbl1 with (index= idx_入學時間年齡)
where ……
如果強制使用你的索引後logical reads大大減少，那麼就需要進一步研究爲什麼SQL Server 不使用正確的索引。注意，不要總是將使用索引等同於好的性能，反之亦然。SQL Server只在索引能提高性能時才使用索引檢索。有時候使用Table scan的性能比使用某個索引反而要好。
問題5、什麼使用聚集索引，什麼時候使用非聚集索引
在SQL Server 中索引有聚集索引和非聚集索引兩種。它們的主要差別是前者的索引葉子就是數據本身，而後者的葉子節點包含的是指向數據的書籤（即數據行號或聚集索引的key）。
在上面的例子中我全部使用非聚集索引，原因是對一個表而言聚集索引只能有一個，而非聚集索引可以有多個。如果你把上面例子中的非聚集索引換成聚集索引，效果也是類似的，只是聚集索引沒有Bookmark Lookup操作。什麼時候應該使用聚集索引，什麼時候使用非聚集索引取決於應用程序的訪問模式。我的建議是在那些關鍵的字段上使用聚集索引。一個表一般都需要建立一個聚集索引。對於什麼時候使用聚集索引，SQL Server 2000聯機手冊中有如下描述：
在創建聚集索引之前，應先了解您的數據是如何被訪問的。可考慮將聚集索引用於：
- 包含大量非重複值的列。
- 使用下列運算符返回一個範圍值的查詢：BETWEEN、>、>=、< 和 <=。
- 被連續訪問的列。
- 返回大型結果集的查詢。
- 經常被使用聯接或 GROUP BY 子句的查詢訪問的列；一般來說，這些是外鍵列。對 ORDER BY 或 GROUP BY 子句中指定的列進行索引，可以使 SQL Server 不必對數據進行排序，因爲這些行已經排序。這樣可以提高查詢性能。
- OLTP 類型的應用程序，這些程序要求進行非常快速的單行查找（一般通過主鍵）。應在主鍵上創建聚集索引。
聚集索引不適用於：
- 頻繁更改的列
這將導致整行移動（因爲 SQL Server 必須按物理順序保留行中的數據值）。這一點要特別注意，因爲在大數據量事務處理系統中數據是易失的。
- 寬鍵
來自聚集索引的鍵值由所有非聚集索引作爲查找鍵使用，因此存儲在每個非聚集索引的葉條目內。
七、結束語
如何使一個性能緩慢的系統運行更快更高效，不但需要整體分析數據庫系統，找出系統的性能瓶頸，更需要優化數據庫系統發出的SQL 語句。一旦找出關鍵的SQL 語句並加與優化，性能問題就會迎刃而解。讀完本文，你應該知道創建索引的關鍵是什麼，以及如何分析SQL語句的執行計劃來創建索引。在優化了索引後大部分數據庫系統的性能都能夠得到不同程度的改善，有的系統甚至能夠獲得好幾倍以上的性能提升。本文並不能解決你在優化SQL語句中碰到的所有問題，但其中討論的內容或技巧對許多性能問題都有一定的參考意義。