磁盤 I/O 并行度
為了改善存儲在多個磁盤驅動器上的大型 SQL Server 數據庫的性能，一個有效的方法是創建磁盤 I/O 并行機制，該機制同時對多個磁盤驅動器進行讀寫操作。RAID 通過硬件和軟件實現磁盤 I/O 并行度。下一個主題討論使用分區來組織 SQL Server 數據以進一步增加磁盤 I/O 并行度。
| 使用分區來提高性能 |  |
 | |
對于存儲在多個磁盤驅動器上的 SQL Server 數據庫，可通過對數據進行分區以增加磁盤 I/O 并行度來改善性能。
可使用多種方法來進行分區。分區的創建和管理方法包括配置存儲子系統（磁盤、RAID 分區）和在 SQL Server 中應用各種數據配置機制（例如，文件、文件組、表和視圖）。雖然本節重點介紹一些與性能相關的分區功能，但是第 18 章“在 SQL Server 2000 數據倉庫中使用分區”也特別介紹了分區主題。
創建磁盤 I/O 并行度的最簡單方法是，使用硬件分區并創建一個為所有的 SQL Server 數據庫文件（事務日志文件除外，它們總是應當存儲在從物理上分開且僅專用于日志文件的磁盤驅動器上）提供服務的驅動器池。驅動器池可以是一個 RAID 陣列，它在 Windows 中呈現為一個物理驅動器�？梢允褂枚鄠� RAID 陣列和 SQL Server 文件/文件組來設置較大的池�？梢詫⒁粋� SQL Server 文件與每個 RAID 陣列相關聯，并將這些文件組合成一個 SQL Server 文件組。然后，可基于該文件組構建一個數據庫，以便將數據均勻地分布到所有的驅動器和 RAID 控制器上。驅動器池方法依賴 RAID 在所有的物理驅動器之間劃分數據，這樣有助于確保在數據庫服務器操作過程中對該數據進行并行訪問。
該驅動器池方法簡化了 SQL Server I/O 的性能優化，因為數據庫管理員知道只有一個物理位置可供創建數據庫對象�？杀O視單個驅動器池的磁盤隊列情況，必要時可向該池中添加更多的硬盤驅動器以防出現磁盤排隊現象。一般情況下，無法確定數據庫哪些部分的利用率最高，此時使用該方法有助于優化性能。最好不要只是因為 SQL Server 可能要用 5% 的時間來對另一磁盤分區進行 I/O 而將總體可用 I/O 能力的一部分隔離到該磁盤分區上�！皢蝹�驅動器池”方法有助于使所有可用的 I/O 能力對于 SQL Server 操作“始終”可用。它還允許 I/O 操作分布到最大數量的可用磁盤上。
SQL Server 日志文件始終 都應該從物理上分散到不同的硬盤驅動器，與所有其他 SQL Server 數據庫文件分開。對于管理多個繁忙數據庫的極其繁忙的 SQL Server 來說，每個數據庫的事務日志文件應當在物理上互相分離，以減少爭用現象。
由于事務日志記錄主要是順序寫入 I/O，所以將日志文件分開往往會顯著提高 I/O 性能。包含日志文件的磁盤驅動器可以非常高效地執行這些順序寫入操作，但前提是這些操作不被其他 I/O 請求中斷。有時，將需要在 SQL Server 操作（例如，復制、回滾和延遲更新）過程中讀取事務日志。有些實現通過將新數據幾乎實時地裝載到數據倉庫中，將復制用作其數據轉換實用工具的前端。參與復制的 SQL Server 的管理員需要確保所有用于事務日志文件的磁盤都有足夠的 I/O 處理能力，以便處理除正常日志事務寫入之外需要發生的讀取操作。
物理上分割的文件和文件組需要額外的管理工作。事實證明，為了隔離和改善對非�；顒拥谋砘蛩饕脑L問而進行分割時，這些額外的工作是值得的。下面列出了一些益處：
- 對于特定對象的 I/O 需求，可以進行更準確的評估，而如果所有數據庫對象都放在一個大驅動器池中，進行這種評估就不那么容易了。
- 使用文件和文件組對數據和索引進行分區，可以增強管理員創建粒度更細的備份和恢復策略的能力。
- 文件和文件組可用于維護數據在磁盤上的順序放置，從而減少或消除非順序的 I/O 活動。如果數據裝載到數據倉庫的可用時間窗口要求并行執行處理以滿足最終期限，則該功能就變得尤其重要。
- 在數據庫開發和基準檢驗階段，可能適于對文件和文件組進行物理分割，這樣可收集數據庫 I/O 信息并將其應用于生產數據庫服務器環境的容量計劃。
有關對象分區的注意事項
可以在不同的硬盤驅動器、RAID 控制器和 PCI 通道（或者三者的組合）之間分隔以下方面的 SQL Server 活動：
- 事務日志
- tempdb
- 數據庫
- 表
- 非聚集索引
注意 在 SQL Server 2000 中，Microsoft 增強了分布式分區視圖，使用這種視圖可以創建聯合數據庫（通常稱作擴展），這種數據庫會將資源負荷和 I/O 活動分布到多個服務器上。聯合數據庫適于某些高端聯機分析處理 (OLTP) 應用程序，但是建議不要使用該方法來解決數據倉庫的需求。
使用硬件 RAID 控制器、RAID 熱插拔驅動器和聯機 RAID 擴展功能可以輕松實現對 SQL Server I/O 活動的物理分割。最靈活的方法是排列 RAID 控制器，讓單獨的 RAID 通道與上述不同活動方面相關聯。同樣，應當將每個 RAID 通道連接到一個單獨的 RAID 熱插拔機柜，以便充分利用聯機 RAID 擴展功能（如果可通過 RAID 控制器使用該功能）。隨后，Windows 邏輯驅動器盤符將會與每個 RAID 陣列相關聯，并且 SQL Server 文件會基于已知的 I/O 使用模式在不同的 RAID 陣列之間被分隔開。
使用這種配置，有可能將與每個活動相關聯的磁盤隊列重新與一個不同的 RAID 通道及其驅動器機柜相關聯。如果某個 RAID 控制器及其驅動器陣列機柜均支持聯機 RAID 擴展功能，而且機柜中有熱插拔硬盤驅動器的插槽，則只需向 RAID 陣列中添加更多的驅動器，直到系統監視器報告該 RAID 陣列的磁盤隊列已經達到可接受的程度（對于 SQL Server 文件最好少于兩個），即可解決該 RAID 陣列的磁盤隊列問題。這可以在 SQL Server 聯機時完成。
分離事務日志
維護事務日志文件的存儲設備應該在物理上與數據文件所在的設備分開。根據您的數據庫恢復模型設置不同，大多數更新活動既產生數據設備活動又產生日志活動。如果將這兩個活動設置為共享同一個設備，則要執行的操作將爭用同一個有限資源。大多數安裝都受益于將這些競爭 I/O 活動分開。
分離 tempdb
SQL Server 會在每個服務器實例上創建一個名為 tempdb 的數據庫，以供服務器用作各種不同活動的共享工作區，這些活動包括：臨時表、排序、處理子查詢、生成聚合以支持 GROUP BY 或 ORDER BY 子句、使用 DISTINCT 的查詢（必須創建臨時工作表才能刪除重復行）、游標，以及哈希聯接。通過將 tempdb 分割到其自己的 RAID 通道上，我們使 tempdb I/O 操作能夠與它們的相關事務的 I/O 操作并行發生。由于 tempdb 實際上是一個草稿區域，而且更新頻繁，所以 RAID 5 對于 tempdb 并不是好的選擇，而 RAID 1 或 0+1 提供的性能更好。雖然 Raid 0 不提供容錯功能，但可以考慮將它用于 tempdb，因為每次重新啟動數據庫服務器時都會重新生成 tempdb。RAID 0 使用最少的物理驅動器為 tempdb 帶來了最佳的 RAID 性能，但在生產環境中將 RAID 0 用于 tempdb 時主要的顧慮是：如果有物理驅動器（包括用于 tempdb 的驅動器）出現故障，就可能影響到 SQL Server 的可用性。如果將 tempdb 放在具備容錯能力的 RAID 配置上，就可以避免這一點。
要移動 tempdb 數據庫，請使用 ALTER DATABASE 命令更改與 tempdb 相關聯的 SQL Server 邏輯文件名的物理文件位置。例如，要將 tempdb 以及與之相關聯的日志移到新文件位置 E:\mssql7 和 C:\temp，請使用以下命令：
alter database tempdb modify file (name='tempdev',filename=
'e:\mssql7\tempnew_location.mDF')
alter database tempdb modify file (name='templog',filename=
'c:\temp\tempnew_loglocation.mDF')
與用戶數據庫相比，master 數據庫 msdb 和model 數據庫在生產過程中很少使用，因此，在考慮優化 I/O 性能時，通常不必考慮它們。master 數據庫通常只用于添加新登錄、數據庫、設備和其他系統對象。
數據庫分區
可以使用文件和/或文件組對數據庫進行分區。文件組只是為管理目的而將多個單獨的文件組合在一起的命名集合。一個文件不能是多個文件組的成員。表、索引、text、ntext 和 image 數據都可以與一個特定的文件組相關聯。這就是說，它們所有的頁都是從該文件組中的文件中分配而來的。下面介紹三種類型的文件組。
主文件組
該文件組包含主數據文件以及未放到另一個文件組中的所有其他文件。系統表的所有頁都是從主文件組分配的。
用戶定義的文件組
該文件組是使用 CREATE DATABASE 或 ALTER DATABASEfilegroup 語句中的 FILEGROUP 關鍵字或者在 SQL Server 企業管理器中的屬性對話框上指定的任何文件組。
默認文件組
默認文件組包含在創建時未指定文件組的所有表和索引的頁。在每個數據庫中，每次只能有一個文件組是默認文件組。如果未指定默認文件組，則主文件組就是默認文件組。
文件和文件組對于控制數據和索引的位置以及消除設備爭用現象很有用。有相當一部分安裝還將文件和文件組用作一種比數據庫粒度更細的機制，以便對它們的數據庫備份/恢復策略進行更多的控制。
水平分區（表）
水平分區將一個表分割成多個表，每個表都包含相同的列數，但是行數會減少。怎樣對表進行水平分區要根據分析數據的方式而定。根據一般經驗，在對表進行分區時，應當使查詢引用的表盡可能少。否則，用于在查詢時按邏輯合并表的 UNION 查詢就會過多，從而會影響性能。
例如，假定企業要求規定：我們要將十年來不斷滾動的事務數據存儲到我們數據倉庫的中央事實表中。我們公司十年來的事務數據意味著數據會超過十億行。數量達到十億的任何內容管理起來都會很困難�，F在，請考慮每年我們都必須除去第十年的數據，然后裝載最新一年的數據。
管理員通常采用的方法是：創建十個獨立但結構相同的表，每個表中存放一年的數據。然后，管理員在這十個表的基礎上定義一個聯合視圖，以便讓最終用戶看到所有數據都放在一個表中。實際上并非如此。針對該視圖執行的任何查詢都被優化成只搜索指定的年份（和相應的表）。不過，管理員確實獲得了管理能力�，F在，管理員能夠以粒度方式單獨管理每年的數據。每年的數據都可以單獨裝載、索引或維護。添加新年份就是這樣簡單：除去該視圖，除去包含第十年數據的表，裝載和索引新年份的數據，然后重新定義新視圖以包括新年份的數據。
當您在多個表或多個服務器之間對數據進行分區時，只訪問部分數據的查詢運行得更快，因為要掃描的數據比較少。如果這些表位于不同的服務器上，或者在一臺具有多個處理器的計算機上，還可以并行掃描查詢所涉及的每個表，從而改善查詢性能。另外，維護任務（例如，重建索引或備份表）的執行速度會更快。
通過使用分區視圖，數據仍顯示為一個表，而且在查詢數據時可以不必手動引用相應的基礎表。如果滿足下列任一條件，分區視圖就可以進行更新。有關分區視圖及其限制的詳細信息，請參閱“SQL Server 聯機叢書”。
- 在該視圖上用可支持 INSERT、UPDATE 和 DELETE 語句的邏輯定義了 INSTEAD OF 觸發器。
- 該視圖以及 INSERT、UPDATE 和 DELETE 語句遵循為可更新的分區視圖定義的規則。
分離非聚集索引
索引駐留在 B 型樹結構中，通過使用 ALTER DATABASE 命令來設置一個不同的文件組，這些索引可以與它們的相關數據庫表分開（聚集索引除外）。在下面的示例中，第一個 ALTER DATABASE 創建一個文件組。第二個 ALTER DATABASE 向新創建的文件組中添加一個文件。
alter database testdb add filegroup testgroup1
alter database testdb add file (name = 'testfile',
filename = 'e:\mssql7\test1.ndf') to filegroup testgroup1
在創建了文件組及其關聯的文件之后，可以在創建索引時指定該文件組，從而使用該文件組來存儲索引。
create table test1(col1 char(8))
create index index1 on test1(col1) on testgroup1
SP_HELPFILE 會將有關給定數據庫中文件和文件組的信息反饋回來。SP_HELP <表名> 的輸出結果中有一節，該節提供有關表的索引及其文件組關系的信息。
sp_helpfile
sp_help test1
并行數據檢索
SQL Server 在具有多個處理器的計算機上運行時可以并行掃描數據。如果一個表在包含多個文件的文件組中，則可以對該表執行多個并行掃描。只要按順序訪問某個表，就會創建一個獨立線程來并行讀取每個文件。例如，如果完全掃描在包含四個文件的文件組上創建的表，將會使用四個獨立線程來并行讀取數據。因此，為每個文件組創建多個文件會有助于提高性能，因為這樣會使用獨立的線程來并行掃描每個文件。同樣，當某個查詢聯接著不同文件組上的表時，可以并行讀取每個表，從而改進查詢性能。
另外，表中的任何 text、ntext 或 image 列都可以在除基表所在文件組以外的文件組上創建。
最終，文件過多會導致并行線程過多，進而導致磁盤 I/O 子系統中出現瓶頸，這時就會達到飽和點。通過使用系統監視器來監視 PhysicalDisk 對象和磁盤隊列長度計數器，可以確定這些瓶頸。如果磁盤隊列長度計數器大于 3，請考慮減少文件數量。
為了通過使用多個文件并行訪問數據來提高吞吐量，將盡可能多的數據分布到盡可能多的物理驅動器上是很有益處的。要將數據均勻地分布到所有磁盤上，請首先設置基于硬件的磁盤條帶化，然后根據需要使用文件組將數據分布到多個硬件條帶集上。
并行查詢建議
SQL Server 可自動以并行方式執行查詢。這樣就會對在多處理器計算機上執行查詢進行優化。工作會細分為多個線程（受線程和內存的可用性影響），而不是一個查詢用一個操作系統線程執行，這樣，完成復雜查詢時就會速度更快，效率更高。
SQL Server 中的優化器會為查詢生成計劃并確定將在何時并行執行查詢。確定時會依據以下條件：
- 計算機是否有多個處理器？
- 是否有足夠的內存來并行執行查詢？
- 服務器上的 CPU 負荷是多少？
- 正在運行哪種類型的查詢？
如果允許 SQL Server 以并行方式運行并行操作（例如 DBCC 和創建索引），對服務器資源的壓力就會變重，而且在執行繁重的并行操作任務時，您可能會看到警告信息。如果服務器錯誤日志中經常出現有關資源不足的警告消息，請考慮使用系統監視器來調查哪些資源（例如，內存、CPU 使用率和 I/O 使用率）可用。
當服務器上有活動用戶時，請不要并行運行大量查詢。請嘗試在沒有負載的時間段中執行維護作業（例如，DBCC 和創建索引）。這些作業可以并行執行。監視磁盤 I/O 性能。觀察系統監視器（在 Windows NT 4.0 中為性能監視器）中的磁盤隊列長度，確定是升級硬盤還是將數據庫重新分布到不同的磁盤上。如果 CPU 的使用率非常高，請升級或添加更多的處理器。
下列服務器配置選項可能會影響查詢的并行執行：
- 并行度的成本閾值
- 最大并行度
- 最大工作線程
- 查詢調控器成本限制
優化數據負荷
在加速數據裝載活動時，一定要記住多種提示和方法。根據您執行的是初始數據裝載還是增量數據裝載，這些方法可能會有所不同。一般來說，增量裝載更復雜且限制性更強。您選擇的方法可能還基于您無法控制的因素。處理窗口要求、所選存儲配置、服務器硬件的限制等都會影響可供您使用的選項。
在執行初始數據裝載和增量數據裝載時，有一些共同的要點需要記住。下面將詳細討論以下主題：
- 選擇適當的數據庫恢復模型
- 使用 bcp、BULK INSERT 或大容量復制 API
- 控制鎖定行為
- 并行裝載數據
- 雜項，其中包括：
- 繞過引用完整性檢查（約束和觸發器）
- 裝載預先排序的數據
- 刪除索引帶來的影響
選擇適當的數據庫恢復模型
我們已在“影響性能的配置選項”一節中討論了數據庫恢復模型。一定要記住所選恢復模型對執行數據裝載所需的時間可能會有很大的影響。這些恢復模型主要控制將寫出到事務日志中的數據量。因為對事務日志執行寫入操作基本上會使工作負荷加倍，所以這非常重要。
日志記錄和最小日志記錄大容量復制操作
在使用完全恢復模型時，由某個大容量數據裝載機制（將在下面討論）執行的所有插入行操作都記錄到事務日志中。對于大型數據裝載，這可能會導致快速填充事務日志。為了幫助防止事務日志的空間不足，可執行最小日志記錄大容量復制操作。是以日志記錄還是以無日志記錄形式執行大容量復制不作為大容量復制操作的一部分來指定；它取決于大容量復制中涉及到的數據庫和表的狀態。如果符合以下所有的條件，將進行無日志記錄的大容量復制：
- 恢復模型是“簡單”或“大容量日志記錄的”，或者數據庫選項 select into/bulkcopy 設置為真。
- 目標表未在進行復制。
- 目標表沒有索引，或者如果目標表有索引，在開始大容量復制時它也是空的。
- TABLOCK 提示是在將 eOption 設置為 BCPHINTS 的情況下使用 bcp_control 指定的。
任何不滿足上述條件的向 SQL Server 實例中進行的大容量復制將完全記錄下來。
在執行初始數據裝載時，應當總是在“大容量日志記錄的”或“簡單”恢復模型下運行。對于增量數據裝載，只要數據丟失的可能性很低，就考慮使用“大容量日志記錄的”模型。因為許多數據倉庫基本上都是只讀的或者事務活動的數量很少，所以將數據庫恢復模型設置為“大容量日志記錄的”不會產生任何問題。
使用 bcp、BULK INSERT 或大容量復制 API
SQL Server 內部存在兩個機制，用來解決大容量移動數據的需求。第一個機制是 bcp 實用工具。第二個機制是 BULK INSERT 語句。bcp 是一個命令提示符實用工具，它既將數據復制到 SQL Server 中又從其中復制數據。在 SQL Server 2000 中，bcp 實用工具是用 ODBC 大容量復制應用程序編程接口 (API) 重新編寫的。bcp 實用工具的早期版本是使用 DB-Library 大容量復制 API 編寫的。
BULK INSERT 是 SQL Server 附帶的 Transact-SQL 語句，該語句可從數據庫環境內執行。與 bcp 不同的是，BULK INSERT 只能將數據拉入 SQL Server 中。它不能將數據推出。使用 BULK INSERT 的一個好處在于，它可以使用 Transact-SQL 語句將數據復制到 SQL Server 的實例中，而不必退出解釋器轉到命令提示符中。
第三個選項是大容量復制 API，程序員通常對該選項很感興趣。有了這些 API，程序員就能夠使用 ODBC、OLE DB、SQL-DMO 或者甚至基于 DB 庫的應用程序將數據移入或移出 SQL Server。
所有這些選項都使您能夠對批處理大小進行控制。除非您使用的是小容量數據，否則最好習慣于指定批處理大小以進行恢復。如果未指定批處理大小，則 SQL Server 將所有要裝載的行作為一批提交。例如，您嘗試將 1,000,000 行新數據裝載到某個表中。服務器在處理完第 999,999 行后突然斷電。當服務器恢復時，將需要從數據庫中回滾處理完的 999,999 行，然后再嘗試重新裝載數據。您可以通過將批處理大小指定為 10,000 來大大節省自己的恢復時間，這是由于您已經將 1 到 990,000 行提交到數據庫中，因此將只需回滾 9,999 行（而不是 999,999 行）。同樣，如果未指定批處理大小，則將必須從第 1 行重新啟動裝載處理才能重新裝載數據。如果將批處理大小指定為 10,000 行，則只需從第 990,001 行重新啟動裝載處理，這樣就高效地繞過了已經提交的 990,000 行。
控制鎖定行為
bcp 實用工具和 BULK INSERT 語句接受 TABLOCK 提示，該提示允許用戶指定要使用的鎖定行為。TABLOCK 指定在大容量復制操作過程中將采用大容量更新表級鎖。使用 TABLOCK 可以減少表上對鎖的爭用，從而改進大容量復制操作的性能。當針對單個表處理并行裝載時，該設置有非常重要的含義（將在下一節討論）。
例如，要將 Authors.txt 數據文件中的數據大容量復制到 pubs 數據庫中的 authors2 表中，請指定表級鎖，并從以下命令行提示符執行：
bcp pubs..authors2 in authors.txt -c -t, -Sservername -Usa -Ppassword -h "TABLOCK"
或者，您可以從查詢工具（如 SQL 查詢分析器），使用 BULK INSERT 語句來大容量復制數據，如下例所示：
BULK INSERT pubs..authors2 FROM 'c:\authors.txt'
WITH (
DATAFILETYPE = 'char',
FIELDTERMINATOR = ',',
TABLOCK
)
如果未指定 TABLOCK，除非對于表將 table lock on bulk load 選項設置為 on，否則默認鎖定會使用行級鎖。將 table lock on bulk load 選項與 sp_tableoption 命令一起使用，也可以設置大容量裝載操作過程中表的鎖定行為。
| Table lock on bulk load | 表的鎖定行為 |
|---|---|
| Off | 使用行級鎖 |
| On | 使用表級鎖 |
注意 如果指定了 TABLOCK 提示，則在大容量裝載過程中，它將替代使用 sp_tableoption 聲明的設置。
并行裝載數據
并行裝載 — 非分區表
使用 SQL Server 中的任一大容量數據裝載機制，都可以將數據并行裝載到一個非分區表中。這是通過同時運行多個數據裝載來完成的。在開始裝載之前，需要將要并行裝載的數據拆分成多個獨立文件（大容量插入 API 的數據源）。然后，可同時啟動所有的獨立裝載操作，以便并行裝載數據。
例如，假設您需要為在全球四個地區運作的服務公司裝載合并的數據庫，每個地區每個月都報告寄給客戶的帳單上的報告時間（小時）。對于大型服務組織，這可能表示需要合并大量事務數據。如果這四個報告地區都分別提供獨立文件，則可以使用上面介紹的方法將這四個文件同時裝載到一個表中。
注意 并行處理的并行線程（裝載）的數量不應超過 SQL Server 的可用處理器數。
下面的插圖說明了對非分區表進行的并行裝載。
如果您的瀏覽器不支持嵌入式框架，請單擊此處在單獨的頁中查看。
并行裝載：水平分區（表）
本節重點介紹如何使用水平分區表來提高數據裝載的速度。在上一節中，我們討論了將數據從多個文件裝載到一個（非分區）表中。如果對表進行水平分區，則可以減少設備爭用現象，從而有機會改善數據的連續性并加速裝載過程。雖然上圖顯示的是數據裝載到了表的不同部分中，但這樣的表述可能不準確。如果上述裝載中的所有三個線程是同時處理的，為該表提取的擴展盤區最后就可能會是混合狀態。在數據混合后，可能導致在檢索數據時無法實現最佳性能。這是由于數據不是按物理上連續的順序存儲的，從而可能導致系統使用不連續的 I/O 訪問它。
在該表基礎上生成聚集索引將解決上述問題，因為數據會按連續順序被讀入、按鍵順序排序，并被回寫。但是，讀取、排序、刪除舊數據以及將新排序的數據回寫可能是一項非常耗時的任務（請參閱下面的裝載預先排序的數據）。為避免出現這種混合的情形，請考慮使用文件組在可以存儲大表的位置保留多塊連續空間。許多安裝還使用文件組將索引數據與表數據分開。
為便于闡述，假定有一個數據倉庫分配在一個大型物理分區上。任何對該數據庫并行執行的裝載操作都有可能導致以非連續（混合）狀態存儲受影響的數據/索引頁。將執行哪種操作？任何對數據進行修改的操作都將導致數據變得不連續。為了滿足處理窗口的要求，用戶可能會嘗試并行執行初始數據裝載、增量數據裝載、索引創建、索引維護、插入、更新、刪除等活動。
下面的插圖顯示的是跨多個文件組對表分區。
如果您的瀏覽器不支持嵌入式框架，請單擊此處在單獨的頁中查看。
裝載預先排序的數據
SQL Server 的早期版本提供了一個選項，您可以在創建索引時用它來指定 SORTED_DATA 選項。SQL Server 2000 取消了這個選項。在早期版本中，將該選項指定為 CREATE INDEX 語句的一部分是：它能夠讓您在索引創建過程中避免排序的步驟。默認情況下，在 SQL Server 中創建聚集索引時，表中數據會在處理過程中排序。要在 SQL Server 2000 中獲得同樣的效果，請考慮在大容量裝載數據之前創建聚集索引。SQL Server 2000 中的大容量操作使用了增強的索引維護策略，這樣，對于已具有聚集索引的表，可以改進數據導入性能，而且在導入之后不需要對數據重新排序。
FILLFACTOR 和 PAD_INDEX 對數據裝載的影響
FILLFACTOR 和 PAD_INDEX 將在題為“索引和索引維護”的一節中更完整地介紹。對于 FILLFACTOR 和 PAD_INDEX，都需要記住關鍵的一點：創建索引時，如果將它們保留為默認值設置，可能會導致 SQL Server 為存儲數據而執行比必需數量多的寫入和讀取 I/O 操作。如果數據倉庫中沒有發生多少寫入活動但發生了大量讀取活動，則更是如此。要讓 SQL Server 在一頁數據頁或索引頁中寫入更多的數據，您可以在創建索引時指定特定的 FILLFACTOR。最好在提供覆蓋 FILLFACTOR 值時指定 PAD_INDEX。
初始數據裝載的一般準則
在裝載數據時
- 刪除索引（唯一的例外可能是在裝載預先排序的數據時，請參閱上文）
- 使用 BULK INSERT、bcp 或大容量復制 API
- 使用分區數據文件并行裝載到分區表中
- 對于每個可用的 CPU 運行一個裝載流
- 設置“大容量日志記錄的”或“簡單”恢復模型
- 使用 TABLOCK 選項
在裝載數據之后
- 創建索引
- 切換到相應的恢復模型
- 執行備份
增量數據裝載的一般準則
- 用索引將數據裝載到適當位置。
- 應當根據性能和并發要求來確定鎖定粒度 (sp_indexoption)。
- 除非特別需要保留時點恢復（例如，聯機用戶在大容量裝載過程中修改數據庫），否則請將恢復模型從“完全”更改為“大容量日志記錄的”。讀取操作不應當影響大容量裝載。
索引和索引維護
前面已經討論了服務器硬件設備的 I/O 特征�，F在，我們將討論 SQL Server 數據和索引結構在物理上是如何放置在磁盤驅動器上的。如果要在設計完成之后改善性能，則索引位置有可能是影響數據倉庫的一個最大因素。
SQL Server 中的索引類型
雖然 SQL Server 2000 引入了幾種新索引類型，但它們全部都基于兩個核心窗體。這兩個核心窗體的格式是聚集索引或非聚集索引。在 SQL Server 中，數據庫設計人員可以使用以下兩種主要類型的索引：
- 聚集索引。
- 非聚集索引。
這兩個主要類型的其他變體包括：
- 唯一索引。
- 計算列的索引。
- 索引視圖。
- 全文索引。
以下各節將詳細介紹上面提到的每種索引（全文索引除外）。全文索引是一種特殊情況，它與其他數據庫索引不同，本章不對它進行介紹。索引視圖是 SQL Server 2000 中新引入的一種索引，它應該會引起數據倉庫用戶的特別關注。SQL Server 2000 中引入的另一項新功能是按升序或降序創建索引。
索引的工作原理
數據庫中的索引類似于圖書中的索引。在一本書中，您使用索引可以迅速找到信息，而不必讀完全書。在一個數據庫中，數據庫程序使用索引可以找到表中的數據，而不必掃描整個表。書中的索引是一個字詞以及各字詞所在頁碼的列表。數據庫中的索引是表中的值以及各值存儲位置（在表中所在的行）的列表。
索引可以針對表中的一列或一組列創建，并以 B 樹的形式實現。索引包含一個條目以及一個或多個對應于表中每一行的列（搜索鍵）。B 樹根據搜索鍵的排序次序按升序或者降序（視創建索引時所選選項而定）存儲，利用該搜索鍵的任何前導子集，可以高效地搜索到 B 樹。例如，利用以下組合，可以高效地搜索 A、B、C 列的索引：A；A 和 B；A、B 和 C。
當您創建數據庫并優化其性能時，應當為查詢中使用的列創建用來查找數據的索引。在 SQL Server 附帶的 pubs 示例數據庫中，在 employee 表的 emp_id 列有一個索引。當用戶執行的語句根據指定的 emp_id 值在 employee 表中查找數據時，SQL Server 查詢處理器識別 emp_id 列的索引并使用該索引來查找數據。下面的插圖說明了該索引如何存儲每個 emp_id 值并指向表中具有相應值的數據所在的行。
如果您的瀏覽器不支持嵌入式框架，請單擊此處在單獨的頁中查看。
但是，帶索引的表需要在數據庫中占用更多的存儲空間。同樣，用來插入、更新或刪除數據的命令的運行時間以及維護索引所需的處理時間會更長。您在設計和創建索引時，一定要注意：性能益處比存儲空間和處理資源所導致的額外成本更加重要。
索引交集
SQL Server 查詢處理器中有一項獨特的功能：執行索引交集。這是一種特殊形式的索引覆蓋，我們將在以后詳述，但是現在因以下兩個原因而需要提及索引交集。第一，它是一種可能會影響您的索引設計策略的技術。
第二，該技術可能會減少您需要的索引數，從而可以大大節省大型數據庫占用的磁盤空間。
索引交集允許查詢處理器使用多個索引來解決查詢。大多數數據庫查詢處理器在嘗試解決查詢時都只使用一個索引。SQL Server 可以組合給定表或視圖中的多個索引，基于這些索引生成哈希表并利用哈希表來減少給定查詢的 I/O 操作。就本質而言，從索引交集中生成的哈希表變成了覆蓋索引，而且，它提供的 I/O 性能與覆蓋索引提供的相同。在數據庫用戶環境中，很難預先確定將針對該數據庫運行的所有查詢，而索引交集為這種環境提供了更大的靈活性。在這種情況下，較好的策略是針對所有經常會被查詢的列定義單列的非群集索引，并讓索引交集處理來需要覆蓋索引的情形。
下面的示例使用了索引交集：
Create index Indexname1 on Table1(col2)
Create index Indexname2 on Table1(col3)
Select col3 from table1 where col2 = 'value'
在執行上面的查詢時，可以通過組合這些索引來快速高效地解決該查詢。
SQL Server 中的索引結構
SQL Server 中所有的索引在物理上都是基于存儲在 8 KB 索引頁上的 B 樹索引結構構建的。每個索引頁都有一個頁頭，頁頭后面是索引行。每個索引行都包含一個鍵值和一個指向行級索引頁或實際數據行的指針。索引中的每一頁又被稱作一個索引節點。B 樹的頂層節點被稱作根節點。索引中的底層節點被稱作葉節點。根和葉之間的任何索引層都統稱為中級層或節點。每層索引中的頁都在雙向鏈接列表中鏈接在一起。
SQL Server 數據頁和索引頁的大小均為 8 KB。SQL Server 數據頁包含所有與表中某行關聯的數據（文本和圖像數據可能除外）。就文本和圖像數據而言，在默認情況下，包含與該文本或圖像列關聯的行的 SQL Server 數據頁將包含一個指針，該指針指向一個或多個包含該文本或圖像數據的 8 KB 頁的二進制樹（或 B 樹）結構。SQL Server 2000 中的一個新功能是能夠將小型文本和圖像值存儲在行中，這意味著小型文本或圖像列將存儲在數據頁上。因為可以避免提取相應的圖像或文本數據所必需的額外 I/O，所以該功能可以減少 I/O 操作。有關如何將表設置為在行中存儲文本或圖像的信息，請參閱“SQL Server 聯機從書”。
聚集索引
聚集索引對于從表中檢索一定范圍的數據值非常有用。非聚集索引最適于檢索特定行，而聚集索引最適于檢索一定范圍的行。但是，由于每個表只允許使用一個聚集索引，因此按照這個簡單的邏輯來確定要創建哪種類型的索引并不總能成功。對于該問題有一個簡單的物理原因。對于聚集索引 B 樹結構的上部（非葉層），如果像對它們的非聚集索引部分那樣組織，則聚集索引的底層由表的實際 8 KB 數據頁組成。但這種情況有一個例外，那就是在視圖的基礎上創建聚集索引時。因為將在下面介紹索引視圖，所以我們將討論針對實際表創建的聚集索引。在針對表創建聚集索引時，會按與索引搜索鍵相同的順序讀取與該表關聯的數據、對這些數據進行排序，并會在物理上將它們存回數據庫。因為該表的數據只能按照一種順序保存到存儲器中，不會導致重復，所以符合一個聚集的限制。
下圖描述了聚集索引的存儲器。
如果您的瀏覽器不支持嵌入式框架，請單擊此處在單獨的頁中查看。
聚集索引和性能
聚集索引有一些會影響性能的固有特征。
在使用聚集索引根據搜索鍵來檢索 SQL Server 數據時，不需要指針跳轉（會導致硬盤上的位置可能不按順序更改）來檢索關聯的數據頁。這是由于聚集索引的葉層實際上就是關聯的數據頁。
如前所述，葉層（當然也包括表或索引視圖的數據）在物理上會按照與搜索鍵相同的順序進行排序和存儲。因為聚集索引的葉層包含表的實際 8 KB 數據頁，所以整個表的行數據會按照由聚集索引確定的順序以物理方式排列在磁盤驅動器上。這就會在根據聚集索引的值從該表中提取大量行（至少大于 64 KB）時帶來潛在的 I/O 性能優勢，因為使用的是順序磁盤 I/O（除非該表上發生了頁拆分，這種情況將在題為“FILLFACTOR 和 PAD_INDEX”的一節中討論）。正因為如此，所以在檢索大量行時，一定要根據將用于執行范圍掃描的列來對表選取聚集索引。
表中與聚集索引相關聯的行必須按照與索引搜索鍵相同的順序排序和存儲，這一點具有以下意義：
- 在您創建聚集索引時，表會被復制，表中的數據會被排序，然后，原來的表會被刪除。所以，數據庫中必須有足夠的空閑空間來存放數據的副本。
- 在默認情況下，會在創建索引時對表中的數據進行排序。但是，如果數據已按正確順序排過序，則會自動跳過排序操作。這樣就可以顯著加快索引創建過程。
- 將數據裝載到表中時的順序應盡可能與您計劃用于生成聚集索引的搜索鍵的順序相同。對于大表（例如那些通常會成為數據倉庫特征的表），該方法將大大加速索引創建過程，從而縮短您處理初始數據裝載所需的時間。只要表中的行仍保持未創建聚集索引時所排的順序，就可以在除去和重建聚集索引時可以使用該方法。任何行排序有誤，操作都會被取消，會出現相應的錯誤信息，而且不會創建索引。
- 同樣，針對排過序的數據生成聚集索引時所需要的 I/O 也少得多，這是因為不必復制數據、對數據進行排序、將數據存回數據庫，然后刪除舊表數據，而是會將數據留在原來分配給它的擴展盤區中。索引擴展盤區只是添加到數據庫中來存儲頂層節點和中間節點。
注意 針對大表生成索引的首選方法是：先生成聚集索引，然后生成非聚集索引。這樣，就不會因為數據移動而需要重新生成非聚集索引。在除去所有索引時，首先會除去非聚集索引，最后除去聚集索引。這樣，就不需要重新生成索引。
