一、概述

在數據庫應用中，速度是一個永恒的話題。有許多因素會影響數據庫的性能表現，例如：操作系統，硬件方面的因素,如內存和磁盤空間，訪問數據庫的應用軟件。除此之外，數據庫本身的設計也是一個影響性能的重要因素。

本文要討論的是我們可以采取哪些措施提高SQL Server數據庫的性能。討論的焦點主要集中在SQL Server 2000為視圖創建索引的能力，以及如何使用Index Tuning Wizard（ITW，索引調整向導）優化索引。另外，我們還要討論如何確保查詢充分地利用了索引以及數據庫統計信息。

性能問題應該在數據庫設計的初始階段就開始考慮。不過，即使在數據庫正式開始運行之后，我們仍舊可以進行一些修改，這些修改將顯著地影響數據庫的性能表現。索引是一種優化數據查詢和排序操作的數據庫實體，正確配置的索引能夠使數據庫查詢或更新數據所需要的時間發生巨大的變化，ITW能夠幫助我們確定如何在數據庫中配置索引以獲得最佳的性能。

我們可以讓ITW根據指定的Workload（工作負荷）推薦最佳的數據庫索引配置。Workload是保存到外部文件的SQL腳本或跟蹤結果。ITW的建議是根據給定Workload而提出的最優化建議，因此事先準備合適的基礎數據非常重要。

為ITW創建工作負荷文件最簡單、最全面的方法或許應該是保存由SQL Profiler創建的跟蹤。SQL Profiler是自SQL Server 7.0開始提供的新工具。它能夠用指定的過濾器和條件，記錄服務器的活動情況。使用SQL Profiler為ITW創建跟蹤時，應當確保跟蹤已經記錄了典型的數據庫活動。換句話說，應當選擇一個數據庫負載不是特別繁重、也不是特別輕松的時段進行跟蹤。至于跟蹤要運行多少長時間，這由系統本身的特點決定。有些時候，我們可能只需跟蹤數小時就可以得到系統典型活動情況的記錄；有些時候，我們可能要讓跟蹤持續幾天，才能記錄下數據庫中所有典型的活動情況。

二、索引調整向導

準備好工作負荷文件之后，我們就可以在Enterprise Manager的樹形視圖中選擇服務器啟動ITW。從Tools菜單選擇Wizards，在樹形視圖中找到Management節點，選擇Index Tuning Wizard，此時我們就可以看到ITW的歡迎屏幕。ITW的第二個屏幕讓我們指定要分析的是哪一個服務器和數據庫。在這個屏幕上，我們還有另外兩個選項：Keep All Existing Indexes（保留現有索引），Perform Thorough Analyses（進行完全分析）。清除Keep All Existing Indexes選項使得ITW能夠提出最優索引建議，但此時ITW可能建議刪除或者修改現有的某些索引。如果你不想修改現有的索引，請保留這個選項的選中狀態。選中Perform Thorough Analyses選項使得ITW進行最廣泛、深入的分析。雖然進行完全分析可能提高分析結果的質量，但它一般需要較長的時間才能完成；而且完全分析運行時，它很可能導致服務器負載過重。由于這些原因，如果你需要執行完全分析，那么最好在測試服務器上進行，或者在正式提供服務的機器上，選擇一個比較空閑的時段進行。

ITW的第三個屏幕讓我們指定對哪一個workload進行分析。如果你使用的是SQL Profiler創建的文件，請選擇My Workload File選項按鈕，然后在文件對話框中找到以前保存的跟蹤文件。在這個屏幕中，點擊Advanced Options命令按鈕可以設置一些高級選項。這些選項包括：被推薦的索引可以使用的最大磁盤空間總量，工作負荷文件中查詢取樣的最大數量。

在第四個屏幕中，我們可以指定ITW應該對哪個或者哪些表的索引提出建議。只選擇那些相關的表有利于節省時間，而且它有助于我們把注意力集中到特定的問題之上。不過，如果要讓ITW對整個數據庫的優化提出建議，我們應該選中數據庫里面所有的表。ITW的下一個屏幕根據我們設定的條件，顯示出它對索引配置的建議（參見圖1）。我們可以選擇立即執行它提出的建議，或者計劃在以后執行，或者把執行腳本保存到外部文件。

ITW不會對主鍵或者其他唯一性索引提出建議，也不會對系統表的索引提出建議。ITW的其他局限還包括：在給定的工作負荷中，它分析的索引不能超過32767個；不能對SQL Server 6.5或者更早版本創建的數據庫提出索引建議。

注意，ITW是以用戶所提供數據的樣本為基礎提出索引配置建議。由于這個原因，你可能會發現：如果讓ITW對同一個工作負荷分析多次，它可能會提出多種不同的索引配置建議。如果ITW不能提出任何建議，它可能是由于下面兩種原因之一造成：第一，與數據庫中現有的索引配置方案相比，ITW無法提出任何能夠進一步提高性能的索引建議；第二；取樣的表里面沒有足夠的數據，無法確定一個合適的索引配置方案。

三、視圖索引

SQL Server 2000企業版除了能夠創建表的索引，它還能夠創建視圖的索引。假設我們對Pubs數據庫中每一份訂單的銷售總量感興趣。下面的代碼在Pubs數據庫中創建一個名為Quantity_Totals的視圖，該視圖除了提供上述信息之外，還提供了訂單所包含項目的總數：

COUNT_BIG是SQL Server 2000提供的一個新函數，它的功能與COUNT函數相同。COUNT_BIG和COUNT的不同之處在于，COUNT_BIG返回值是bigint類型，而COUNT返回值是int類型。任何包含GROUP BY子句的視圖，如果要使用索引就必須包含COUNT_BIG函數。我們可以用SCHEMABINDING選項創建包含索引的視圖。SCHEMABINDING選項是SQL Server 2000的新功能，如果我們指定了SCHEMABINDING選項，視圖將被綁定到其基表的模式。

如果視圖不包含索引，則數據庫中不保存視圖返回的結果集。有的時候，我們可能要創建涉及大量記錄或必須進行復雜計算的視圖，比如要進行聚合分組處理或多重連接操作。如果每次引用這些視圖的時候讓SQL Server重新生成結果集，數據庫開銷將非常大。

視圖的索引與表的索引在作用方式上非常相似。與表一樣，視圖可以有一個集簇索引（Clustered Index）和多個非集簇索引。然而，在創建任何非集簇索引之前，我們必須先為視圖創建一個唯一性的集簇索引。如果我們創建了視圖的集簇索引，數據庫將永久保存視圖的結果集。雖然創建索引時所保存的結果集只反映當時的數據狀態，但任何對基表數據的修改都將自動反應到這個結果集之中。

就象為表創建索引一樣，我們可以用CREATE INDEX命令為視圖創建索引：

上面的代碼為我們前面例子中創建的Quantity_Totals視圖創建了一個唯一性的集簇索引。創建視圖索引不僅能夠提高視圖的性能，而且有些時候性能的提高達到出乎意料的程度。一旦我們為視圖創建并保存了索引，即使對于那些沒有直接在FROM子句中引用該視圖的查詢，Query Optimizer（查詢優化器）也可能選擇使用該視圖索引來提高查詢速度。例如，下面這個SQL命令選擇出按照訂單編號分組的銷售數量累計：

執行這個查詢時，Query Optimizer知道：在SQL Server為Quantity_Totals視圖創建的索引中，這個銷售數量的累計值已經存在。在這種情況下，Query Optimizer會作出這樣的判斷：如果使用為視圖創建的索引，查詢的效率將有很大的提高。

在為視圖創建索引之前，你必須檢查視圖是否滿足創建視圖索引的各種條件。下表列出了這些條件中的一部分：