通過大衛·杜蘭特,2013/01/25(第一次出版:2011/06/22)

該系列

本文是樓梯系列的一部分:SQL Server的階梯索引

索引數據庫設計的基礎,告訴開發人員使用數據庫設計者的意圖。 不幸的是索引時往往是後加上的性能問題出現。 終於在這裏是一個簡單的系列文章,應該讓任何數據庫專業迅速“加速”

前面的水平在這個樓梯概述了非聚集索引的索引一般和特別。 結論用以下關於SQL Server關鍵概念索引。 當一個請求到達您的數據庫,一個SELECT語句或一個INSERT、UPDATE或DELETE語句,SQL Server只有三種可能的方法來訪問數據表中引用的聲明:

• 訪問非聚集索引,避免訪問表。 這只可能在索引中包含的所有數據查詢這個表所要求的
• 使用搜索鍵(s)來訪問索引,然後使用所選的書簽(s)來訪問表的單個行。
• 忽略了索引和搜索請求的表行。

這個水平首先關註的第三選擇上面的列表; 搜索表。 反過來,這將導致我們的討論集群索引; 一個被提及的話題,但沒有涵蓋,在2級

示例數據庫

盡管我們已經討論了在一級sample數據庫,值得重復。 在整個樓梯,我們將使用示例來說明概念。 這些例子是基於微軟的AdventureWorks示例數據庫。 我們專註於銷售訂單。 五表將給我們一個良好的事務性和非事務性數據;客戶,銷售人員,產品,SalesOrderHeader,SalesOrderDetail。 為了保持專註,我們使用列的一個子集。 因為

整個樓梯我們使用以下兩個術語,指一行訂單互換:“行項目”和“訂單細節”。 前者是更常見的業務術語; 後者的名字出現在一個AdventureWorks表。

聚集索引

我們先問以下問題:有多少工作需要找到表中的一行(s)如果不使用非聚集索引? 搜索請求的行表意味著掃描一個無序表中每一行嗎? 永久或SQL Server序列表的行,以便它可以快速訪問他們的搜索鍵,就像快速訪問非聚集索引的搜索鍵的條目嗎? 答案取決於你是否指示SQL Server上創建一個聚集索引表。

與非聚集索引是一個單獨的對象,占據自己的空間,聚集索引和表是一樣的。 通過創建聚集索引,您指示SQL Server排序表的行索引鍵序列,在未來保持序列數據的修改。 即將到來的水平會看看生成的內部數據結構來完成這個。 但是現在,想到一個聚集索引排序表。 鑒於連續索引鍵值,SQL Server可以快速訪問這一行; 並且可以通過表的行順序進行。

出於演示的目的,我們創建兩個我們的示例表的副本,SalesOrderDetail; 一個沒有索引,一個聚集索引。 關於索引的鍵列,我們的設計師做出同樣的選擇AdventureWorks數據庫:SalesOrderID/SalesOrderDetailID。 清單1中的代碼的副本SalesOrderDetail表。 我們可以隨時重新運行這段代碼,我們希望從一個“白紙”開始。

了解基本的聚集索引

聚集索引鍵可以由你選擇的任何列; 它不需要基於主鍵。 在我們的例子中,最重要的是,最左側列的關鍵是一個外鍵,SalesOrderID價值。 因此,銷售訂單的所有行項目中連續出現SalesOrderDetail表。

記住這些額外的點對SQL Server集群索引:

• 由於聚集索引的條目表的行,沒有收藏價值在集群索引條目。 當SQL Server已經在一行,它不需要一個信息,告訴它在哪裏找到這一行。
• 聚集索引總是覆蓋查詢。 自指數和同一個表,表的每一列的索引。
• 桌子上有一個聚集索引不影響你選擇創建非聚集索引表。
• 選擇聚集索引鍵列(s)

• 可以有最多每個表一個聚集索引。 一個表的行可以在只有一個序列。 你需要決定什麽序列,如果有的話,最好為每個表; 如果可能的話,創建聚集索引表變得充滿了之前的數據。 做這個決定時,請記住,測序不僅意味著訂購,這也意味著分組; 在分組由銷售訂單行項目。

  這就是為什麽的設計者AdventureWorks數據庫的選擇SalesOrderDetailID在SalesOrderID的序列SalesOrderDetail表; 行項目的自然順序。
  例如,如果一個用戶請求一個訂單的行項目,他們通常會要求所有訂單的行項目。 看一個典型的銷售訂單的形式告訴我們,訂單的打印副本總是包括所有行項目。 它的本質是銷售訂單業務集群由銷售訂單行項目。 可能會有偶爾的請求從倉庫想看產品而非銷售訂單行項目; 但大多數的請求; 如來自銷售人員或客戶,或程序,打印發票,或查詢,計算每個訂單的總價值; 需要任何銷售訂單的所有行項目。

  用戶需求,然而,不確定什麽是最好的聚集索引。 本系列以後的水平將覆蓋的內部索引; 因為某些內部方面的聚集索引列的索引也會影響你的選擇。

• 堆

  如果沒有聚集索引表,該表稱為堆。 每個表都是一堆或一個聚集索引。 所以,盡管我們經常狀態的每個索引分為兩種類型,集群或非聚集; 同樣重要的是要註意,每個表分成兩個類型; 它是一個聚集索引或一堆。 開發人員經常說一個表“有”或“沒有”一個聚集索引,但它是更有意義的說表”是”或“不是”一個聚集索引。

  只有一種方法為SQL Server來搜索一個堆在尋找行(不含非聚集索引的使用),這是開始在表中的第一行並通過表進行,直到所有的行已經閱讀。 沒有一個序列,沒有搜索鍵,沒有辦法快速導航到特定的行。

  比較一個聚集索引和一堆

  聚集索引的性能評價和一堆,清單1的兩個副本SalesOrderDetail表。 一份是堆版,另一方面,我們創建在原始表的聚集索引(SalesOrderID,SalesOrderDetailID)。 表都沒有任何非聚集索引。

  我們將運行相同的三個查詢每個版本的表; 一個檢索一行,另一個檢索單個訂單,所有行和檢索單個產品的所有行。 我們現在每個執行的SQL和結果表中所示。

• 結論

  聚集索引是一個排序表的序列是由您創建索引時,指定由SQL Server和維護。 該表中的任意行快速訪問給定鍵值。 任何一組行,在索引鍵序列,也很快訪問給定的範圍鍵。

  每個表只能有一個聚集索引。 的決定應該是聚集索引的列索引鍵列是最重要的決定,你會讓任何表。

  在我們的四級我們將把我們的重點從邏輯到物理,介紹頁面和區段,並檢查指標的物理結構。

聚集索引:三級階梯SQL Server索引