程式師世界 >> 數據庫知識 >> 其他數據庫知識 >> MSSQL >> 自增加鍵列統計信息的處置辦法

自增加鍵列統計信息的處置辦法

編輯：MSSQL

自增加鍵列統計信息的處置辦法。本站提示廣大學習愛好者：（自增加鍵列統計信息的處置辦法）文章只能為提供參考，不一定能成為您想要的結果。以下是自增加鍵列統計信息的處置辦法正文

這篇文章經由過程文字代碼的情勢講授了若何處置用自增加鍵列的統計信息。我們都曉得，在SQL Server裡每一個統計信息對象都有聯系關系的直方圖。直方圖用多個步長描寫指定列數據散布情形。在一個直方圖裡，SQL Server最年夜支撐200的步長，但當你查詢的數據規模在直方圖最初步長後，這是個成績。我們來看上面的代碼，重現這個情況：

 -- Create a simple orders table
 CREATE TABLE Orders
 (
  OrderDate DATE NOT NULL,
  Col2 INT NOT NULL,
  Col3 INT NOT NULL
 )
 GO
 
 -- Create a Non-Unique Clustered Index on the table
 CREATE CLUSTERED INDEX idx_CI ON Orders(OrderDate)
 GO
 
 -- Insert 31465 rows from the AdventureWorks2008r2 database
 INSERT INTO Orders (OrderDate, Col2, Col3) SELECT OrderDate, CustomerID, TerritoryID FROM AdventureWorks2008R2.Sales.SalesOrderHeader
 GO
 
 -- Rebuild the Clustered Index, so that we get fresh statistics.
 -- The last value in the Histogram is 2008-07-31.
 ALTER INDEX idx_CI ON Orders REBUILD
 GO
 
 -- Insert 200 additional rows *after* the last step in the Histogram
 INSERT INTO Orders (OrderDate, Col2, Col3)
 VALUES ('20100101', 1, 1)
 GO 200

在索引重建後，我們再看下直方圖，我們發明最初步進的值是2008-07-31。

DBCC SHOW_STATISTICS('dbo.Orders', 'idx_CI') WITH HISTOGRAM

你曾經看到，在最初步進到內外後，我們拔出了200條額定記載。如許的話，直方圖並沒有真實反應現實的數據散布情形，但SQL Server照樣要停止基數盤算。我們如今來看看在分歧版本裡SQL Server是若何處置這個成績的。

SQL Server 2005 SP1- SQL Server 2012

在SQL Server 2014之前，基數盤算對此成績的處置異常簡略：SQL Server估量行數為1，你可以從上面的圖片裡看到。

點擊對象欄的顯示包括現實的履行籌劃，並履行以下查詢：

SELECT * FROM dbo.Orders WHERE OrderDate='2010-01-01'

自SQL Server 2005 SP1起，查詢優化器可以標志1列為自增加（Ascending）來戰勝適才引見的限制。假如你用自增加列值更新了統計信息對象3次，那列就會被標志為自增加列。為了看有無列標志為自增加，你可使用跟蹤標志2388。當你啟用這個跟蹤標志，DBCC SHOW_STATISTICS的輸入就轉變了，有額定列前往。

DBCC TRACEON(2388)
DBCC SHOW_STATISTICS('dbo.Orders', 'idx_CI')

如今上面的代碼更新統計信息3次，每次用自增加鍵列值在我們集合索引末尾拔出行。

 -- => 1st update the Statistics on the table with a FULLSCAN
  UPDATE STATISTICS Orders WITH FULLSCAN
  GO
  
  -- Insert 200 additional rows *after* the last step in the Histogram
  INSERT INTO Orders (OrderDate, Col2, Col3)
 VALUES ('20100201', 1, 1)
  GO 200
  
 -- => 2nd update the Statistics on the table with a FULLSCAN
 UPDATE STATISTICS Orders WITH FULLSCAN
 GO
 
 -- Insert 200 additional rows *after* the last step in the Histogram
 INSERT INTO Orders (OrderDate, Col2, Col3)
 VALUES ('20100301', 1, 1)
 GO 200
 
 -- => 3rd update the Statistics on the table with a FULLSCAN
 UPDATE STATISTICS Orders WITH FULLSCAN
 GO

然後，當我們履行DBCC SHOW_STATISTICS敕令，你會看到SQL Server已講那列標志為Ascending。

DBCC TRACEON(2388)
DBCC SHOW_STATISTICS('dbo.Orders', 'idx_CI')

如今當你再次履行查詢不是直方圖規模的數據時，沒有任何轉變。為了應用標志為自增加鍵列，你要啟用別的一個跟蹤標志-2389。假如你啟用這個跟蹤標志，查詢優化器就是密度向量（Density Vector）來停止基數盤算。

-- Now we query the newly inserted range which is currently not present in the Histogram.
-- With Trace Flag 2389, the Query Optimizer uses the Density Vector to make the Cardinality Estimation.
SELECT * FROM Orders
WHERE OrderDate = '20100401'
OPTION (RECOMPILE, QUERYTRACEON 2389)
GO

來看下如今的表密度：

DBCC TRACEOFF(2388)
DBCC SHOW_STATISTICS('dbo.Orders', 'idx_CI')

如今的表密度是0.0008873115，是以查詢優化器的估量行數是28.4516：0.0008873115*（32265-200）。

這固然不是最好的成果，但比估量行數1好許多！

（這裡有成績，我當地是SQL Server 2008r2，測試估量行數照樣1，不知緣由，望曉得的同伙說明下，多謝！)

SQL Server 2014
在SQL Server 2014引入的一個新功效是新基數盤算。新基數盤算關於自增加鍵成績的處置異常簡略：默許不應用任何跟蹤標志，來應用統計信息對象的密度向量來停止基數盤算。上面查詢啟用2312跟蹤標志的基數盤算來運轉同個查詢。

1 -- With the new Cardinality Estimator SQL Server estimates 28.4516 rows at the Clustered Index Seek operator.
2 SELECT * FROM Orders
3 WHERE OrderDate = '20100401'
4 OPTION (RECOMPILE, QUERYTRACEON 2312)
5 GO

我們來看這裡的基數盤算，你會看到查詢優化器再次估量行數是28.4516，但這一次沒表上自增加。這是SQL Server 2014的自帶功效。

（SQL Server 2014測試掉敗，估量行數也是1……）

在這篇文章，我向你展現了SQL Server的查詢優化器若何處置自增加鍵成績。在SQL Server 2014之前，你須要啟用2389跟蹤標志來取得更好的基數盤算——如許的話那列會標志為自增加（ascending）。SQL Server 2014，查詢優化器默許就應用密度向量來停止基數盤算，如許就便利許多。我願望你對此有所收成，在SQL Server裡若何處置自增加鍵列成績你會有更好的設法主意。

願望對年夜家有所啟發，感謝。