1. 程式人生 > >sql 伺服器統計資訊簡介

sql 伺服器統計資訊簡介

 

sql伺服器統計是包含資料分佈資訊的系統物件.有時,在正則列值中。統計可以在任何支援比較操作的資料型別上建立,例如 > , < , =等。

列表2-15中,dbo.books表中檢視 IDX_BOOKS_ISBN 指數統計資料.您可以通過使用dbcc命令 SHOW_STATISTICS ('dbo.Books',IDX_BOOKS_ISBN )來實現這一點。如圖3-1.

 

正如您所看到的,dbcc show_stums命令返回三個結果集。第一個包含關於統計的一般元資料資訊,如名稱、更新日期、更新統計時索引中的行數等等。第一個結果集中的步數列表示直方圖中的步數

/值(更多關於後面的部分)。該密度值不被查詢優化器使用,僅用於向後相容性目的。

第二個結果集,稱為密度向量,包含了統計(指數)關鍵值組合的密度資訊。它是根據一或多個不同的值公式計算的,並指示每個鍵值組合平均有多少行。

它是根據一或多個不同的值公式計算的,並指示每個鍵值組合平均有多少行。儘管IDX_Books_ISBN指標只定義了一個關鍵列,但它也包含了一個聚集的索引鍵,作為索引行的一部分。我們的表中有1,252,500種獨特的 ISBN值, ISBN列的密度為1.0 / 1,252,500 = 7.984032E-07。所有的組合(ISBNbookid)列也是獨一無二的,並且具有相同的密度。

 

最後一個結果集稱為直方圖。直方圖中的所有記錄,稱為直方圖的步,在統計資料(索引)最左邊的列中包括樣例鍵值,以及關於從前面到當前範圍鍵值範圍內的資料分佈的資訊。讓我們更深入地看直方圖的列。 RANGE_HI_KEY列儲存金鑰的示例值。此值是直方圖步驟定義的範圍的上界鍵值。例如,在圖3-1的直方圖中,記錄(步驟)#3的距離RANGE_HI_KEY = '104-0100002488' 儲存了關於從 ISBN > '101-0100001796'ISBN <= '104-0100002488'

 

     RANGE_ROWS列估計區間內的行數。在我們的例子中,由記錄(步驟)#3定義的間隔有

8,191行。

 

    EQ_ROWS指示有多少行的鍵值等於RANGE_HI_KEY的上界值。就我們的情況而言,只有一行的 ISBN = '104-0100002488' .

 

    DISTINCT_RANGE_ROWS指示間隔內的鍵有多少個不同的值。在我們的例子中,所有的鍵的值都是唯一的,如 DISTINCT_RANGE_ROWS = RANGE_ROWS .

 

    AVG_RANGE_ROWS表示區間內每個獨立鍵值的平均行數。在我們的情況下,所有的鍵的值都是唯一的,所以 AVG_RANGE_ROWS = 1

 

讓我們在索引中插入一組重複的ISBN值,程式碼如圖3-1

 

 

現在,如果您再次執行SHOW_STATISTICS ('dbo.Books',IDX_BOOKS_ISBN ) 命令,您將看到圖3-2所示的結果。

 

字首104ISBN值現在有了重複,這影響了直方圖。還值得一提的是,第二個結果集中的密度資訊也被改變了。

具有重複值的ISBNS的密度高於(isbnbookid)列的組合這個列是唯一的。

執行SELECT BookId, Title FROM dbo.Books WHERE ISBN LIKE 114%’語句,檢查執行計劃,如圖3-3所示。

有兩個重要的屬性,大多數執行計劃運算子都有。實際行數

指示在操作符執行期間處理了多少行。估計行數表示查詢優化階段sql伺服器為該操作符估計的行數。sql伺服器估計有2,625個行,ISNBS114開始。如圖3-2您將看到第10步儲存有關isbn區間資料分佈的資訊,其中包括您選擇的值。即使採用近似線性估計,估計出的行數接近sql伺服器確定的行數。

關於統計,有兩件事要記住。

  1. 直方圖僅為最左邊的統計資料(索引)列儲存有關資料分佈的資訊。有關於統計中關鍵值的多列密度的資訊,但僅此而已。直方圖中的所有其他資訊只涉及最左邊統計列的資料分佈。
  2. sql伺服器在直方圖中最多保留200步,不管表的大小,也不管表是否分割槽。每個直方圖步驟覆蓋的間隔隨著表的增長而增加。過大的表會導致統計資料不太準確。

    對於複合索引,當索引的所有列在所有查詢中用作預測時,將密度較低/唯一值百分比較高的列定義為索引最左邊的列是比較好的。這將使sql伺服器能夠更好地利用統計資料中的資料分佈資訊。然而,你應該考慮這些預測的限制搜尋性(SARG)。例如,如果所有查詢句中使用的都是 [email protected] [email protected]預測,那麼最好將 LastName作為索引中最左邊的列。儘管如此,對於[email protected] and LastName<>@LastName,情況並非如此,在這些預測中, LastName 不是可以限制搜尋的(SARG)。