關(guān)于SQL Server 2014中的基數(shù)估計，官方文檔Optimizing Your Query Plans with the SQL Server 2014 Cardinality Estimator里有大量細節(jié)介紹，但是全部是英文，估計也沒有幾個人仔細閱讀。那么SQL Server 2014中基數(shù)估計的預(yù)估行數(shù)到底是怎么計算的呢？ 有哪一些規(guī)律呢？我們下面通過一些例子來初略了解一下，下面測試案例僅供參考，如有不足或膚淺的地方，敬請指教！
下面實驗測試的環(huán)境主要為SQL Server 2014 SP2 （Standard Edition (64-bit)） 具體版本號為12.0.5000.0 ，如有在其它版本測試，后面會做具體說明。如下所示，我們先創(chuàng)建一個測試表并插入一些測試數(shù)據(jù)后，方便后面的測試工作。
IF EXISTS(SELECT 1 FROM sys.objects WHERE type='U' AND name='TEST_ESTIMATED_ROW')BEGIN DROP TABLE TEST_ESTIMATED_ROW;ENDIF NOT EXISTS(SELECT 1 FROM sys.objects WHERE type='U' AND name='TEST_ESTIMATED_ROW')BEGIN CREATE TABLE TEST_ESTIMATED_ROW ( ID INT, NAME VARCHAR(24) )ENDGODECLARE @Index INT =1;WHILE @Index <= 100BEGIN INSERT INTO TEST_ESTIMATED_ROW VALUES(10, 'id is 10'); SET @Index+=1;ENDGODECLARE @Index INT =1;WHILE @Index <= 200BEGIN INSERT INTO TEST_ESTIMATED_ROW VALUES(20, 'id is 20'); SET @Index+=1;ENDGODECLARE @Index INT =1;WHILE @Index <= 300BEGIN INSERT INTO TEST_ESTIMATED_ROW VALUES(30, 'id is 30'); SET @Index+=1;ENDGODECLARE @Index INT =1;WHILE @Index <= 400BEGIN INSERT INTO TEST_ESTIMATED_ROW VALUES(40, 'id is 40'); SET @Index+=1;ENDGODECLARE @Index INT =1;WHILE @Index <= 500BEGIN INSERT INTO TEST_ESTIMATED_ROW VALUES(50, 'id is 50'); SET @Index+=1;ENDGOCREATE INDEX IX_TEST_ESTIMATED_ROW_N1 ON TEST_ESTIMATED_ROW(ID);GO
我們來看看這個表的統(tǒng)計信息以及直方圖內(nèi)容。
DBCC SHOW_STATISTICS ('dbo.TEST_ESTIMATED_ROW','IX_TEST_ESTIMATED_ROW_N1');GO
SQL Server中有兩種謂詞：過濾謂詞和連接謂詞 。 我們先來看看過濾謂詞的基數(shù)估計（預(yù)估行數(shù)），測試過程，如果要保持測試的公正性或不被其他因素影響，你可以使用下面的DBCC命令來排除干擾，如下例子所示：
DBCC FREEPROCCACHE; --從執(zhí)行計劃緩沖區(qū)刪除所有緩存的執(zhí)行計劃GODBCC DROPCLEANBUFFERS; --從緩沖池中刪除所有緩存，清除緩沖區(qū)GOSELECT * FROM dbo.TEST_ESTIMATED_ROW WHERE ID = 10;GO
（注意，執(zhí)行時請勾選包含實際執(zhí)行計劃按鈕）如上所示，預(yù)估行數(shù)（Estimated Number of Rows）為100,跟實際行數(shù)一致。當(dāng)然你換其他值，例如20， 30， 40 ，50，其預(yù)估行數(shù)（Estimated Number of Rows）跟實際行數(shù)都是正確的（SQL SERVER 2012中測試結(jié)果也相同）。那么如果我換一個不存在的值呢？預(yù)估行數(shù)會是多少呢？
SELECT * FROM dbo.TEST_ESTIMATED_ROW WHERE ID = 4;GO
如上所示，預(yù)估行數(shù)（Estimated Number of Rows）為1. 你換其他任何不存在的值，預(yù)估行數(shù)（Estimated Number of Rows）都為1。這個跟沿用了老的基數(shù)評估：超出統(tǒng)計信息范圍，那么老的基數(shù)評估就認為不存在，評估行數(shù)為1。很顯然，對于沒有超出統(tǒng)計信息范疇的，但是確實不存在的記錄，其預(yù)估行數(shù)（Estimated Number of Rows）也是1，這個基數(shù)估計確實是合理，也是正確的。那么如果我使用變量呢？這個預(yù)估行數(shù)（Estimated Number of Rows）又會是什么值呢？
DECLARE @SID INT = 11; --換任何值都可以SELECT * FROM dbo.TEST_ESTIMATED_ROW WHERE ID = @SID;GO
如上截圖所示，實際執(zhí)行計劃的預(yù)估行數(shù)（Estimated Number of Rows）是300， 那么如何計算來的呢？ 其實你可以根據(jù)公式來計算， 如果不相信，你可以構(gòu)造各種案例測試驗證一下就能得到答案了.
[Row Sampled ]* [ALL density ] = 1500 * 0.2 = 300 也就是統(tǒng)計信息中抽樣總行數(shù)*All Density（統(tǒng)計信息對象中各列的每個前綴的密度）
如果你加上OPTION(RECOMPILE)， 那么預(yù)估行數(shù)（Estimated Number of Rows）又會變成1
DECLARE @SID INT = 11; SELECT * FROM dbo.TEST_ESTIMATED_ROW WHERE ID = @SID OPTION(RECOMPILE)GO
如果你賦予@SID值為20，并加上OPTION(RECOMPILE)時，那么預(yù)估行數(shù)（Estimated Number of Rows）就會變成EQ_ROWS的值了
DECLARE @SID INT = 20; SELECT * FROM dbo.TEST_ESTIMATED_ROW WHERE ID = @SID OPTION(RECOMPILE)GO
接下來，我們修改一下SQL語句，將查詢條件從等于符號改為大于符號，如下所示：
DECLARE @SID INT = 11;SELECT * FROM dbo.TEST_ESTIMATED_ROW WHERE ID > @SID;GO
如上所示，預(yù)估行數(shù)（Estimated Number of Rows）變?yōu)榱?50，那么這個值是怎么計算得來的呢？
計算公式是： [Row Sampled ] * 0.3（30%）
1500 *0.3= 450
肯定會有人問，你怎么知道是 [Row Sampled ] * 0.3 呢？ 不會是你逆推的吧。 不錯，這里是一個推測（網(wǎng)上也有不少資料都確認是0.3，權(quán)且當(dāng)做計算公式中的一個常量），而且也做了不少測試，確實就是30%。例如你將@SID賦值為41，預(yù)估行數(shù)（Estimated Number of Rows）依然為450，如果你懷疑是緩存的執(zhí)行計劃緣故，你可以先清空緩存的執(zhí)行計劃，結(jié)果依然如此。根據(jù)我的測試，不管你給@SID賦予任何值，預(yù)估行數(shù)（Estimated Number of Rows）全部為450
DBCC FREEPROCCACHE;GODBCC DROPCLEANBUFFERS;GODECLARE @SID INT = 41;SELECT * FROM dbo.TEST_ESTIMATED_ROW WHERE ID > @SID;GO
如果SQL加上 OPTION(RECOMPILE) ，然后@SID賦予RANGE_HI_KEY里的值，那么預(yù)估行數(shù)（Estimated Number of Rows）又是如何計算的呢？
DECLARE @SID INT = 20;SELECT * FROM dbo.TEST_ESTIMATED_ROW WHERE ID > @SID OPTION(RECOMPILE);GO
這個1200 是這樣計算的，如下所示，大于20的RANGE_HI_KEY有30 ， 40， 50 ，他們對應(yīng)的EQ_ROWS值相加 300+ 400 + 500 =1200， 不信你可以測試一下，將@SID賦予30，那么預(yù)估行數(shù)（Estimated Number of Rows）就會變成900. 
那么我們再修改一下SQL查詢語句，例如，我們要做一個區(qū)間查詢，預(yù)估行數(shù)（Estimated Number of Rows）又會有什么變化呢？
DBCC FREEPROCCACHE;GODBCC DROPCLEANBUFFERS;GODECLARE @Min_Value INT = 20;DECLARE @Max_Value INT = 50;SELECT * FROM dbo.TEST_ESTIMATED_ROW WHERE ID > @Min_Value AND ID < @Max_ValueGO
如上所示，預(yù)估行數(shù)（Estimated Number of Rows）為246.475 這個值怎么來的呢？其實它是這樣計算的:
Selectivity of most selective predicate * Square root of (selectivity of second most selective predicate) * Total number of rowsSELECT 0.3*SQRT(0.3)*1500 --246.475150877325 --0.3是計算規(guī)則里面的一個常量
那么如果我在SQL Server 2012中執(zhí)行該SQL語句或者使用查詢跟蹤標記9481來關(guān)閉新的基數(shù)評估，數(shù)據(jù)庫優(yōu)化器使用老的基數(shù)評估，你會發(fā)現(xiàn)預(yù)估行數(shù)（Estimated Number of Rows）為135了。如下所示：
DBCC FREEPROCCACHE;GODBCC DROPCLEANBUFFERS;GODECLARE @Min_Value INT = 20;DECLARE @Max_Value INT = 50;SELECT * FROM dbo.TEST_ESTIMATED_ROW WHERE ID > @Min_Value AND ID < @Max_ValueOPTION (QUERYTRACEON 9481);GO
這里的計算公式是
((Estimated number of rows for first predicate) *(Estimated number of rows for second predicate)) /Total number of rows(0.3*1500)*(0.3*1500)/1500 = 0.09*1500 = 135
那么現(xiàn)在我們往表TEST_ESTIMATED_ROW里面插入50條記錄，此時這個數(shù)據(jù)量是不會觸發(fā)統(tǒng)計信息更新的，而此時ID=55的值超出了直方圖中的RANG_HI_KY的最大值50，也就是說直方圖中沒有統(tǒng)計這些新插入的數(shù)據(jù)，那這種情形稱作升序鍵問題（ascending key problem）。在更統(tǒng)計信息新前就對這些數(shù)據(jù)運行查詢，就會發(fā)生此類問題。
DECLARE @Index INT =1;WHILE @Index <= 50BEGIN INSERT INTO TEST_ESTIMATED_ROW VALUES(55, 'id is 50'); SET @Index+=1;ENDGO
那么再來看看下面SQL的預(yù)估行數(shù)（Estimated Number of Rows），如下所示：
DBCC FREEPROCCACHE;GODBCC DROPCLEANBUFFERS;GOSELECT * FROM dbo.TEST_ESTIMATED_ROW WHERE ID = 55;GO
那么預(yù)估行數(shù)（Estimated Number of Rows）為39.37 是怎么計算來的呢？其實這個問題就是http://www.cnblogs.com/wy123/p/6770258.html這篇博客里面提出的問題，先前++C++他在群里面討論了一下。
Optimizing Your Query Plans with the SQL Server 2014 Cardinality Estimator里面介紹，這種是基數(shù)估計的計算公式為 [All density] * [Rows Sampled] 。但是實際測試發(fā)現(xiàn)這個例子并不是如此，那么我們先來親自測試一下白皮書文檔里面的例子（注意，數(shù)據(jù)庫實例是SQL Server 2014，AdventureWorks2012的兼容級別為120）,看看文檔里面的例子是否正確。
SELECT [SalesOrderID], [OrderDate] FROM Sales.[SalesOrderHeader]WHERE [OrderDate] = '2005-07-01 00:00:00.000';SELECT [s].[object_id], [s].[name], [s].[auto_created]FROM sys.[stats] AS sINNER JOIN sys.[stats_columns] AS [sc] ON [s].[stats_id] = [sc].[stats_id] AND [s].[object_id] = [sc].[object_id]WHERE [s].[object_id] = OBJECT_ID('Sales.SalesOrderHeader') AND COL_NAME([s].[object_id], [sc].[column_id]) = 'OrderDate';可以看到OrderDate的統(tǒng)計信息為_WA_Sys_00000003_4B7734FF
DBCC SHOW_STATISTICS('Sales.SalesOrderHeader', _WA_Sys_00000003_4B7734FF);
從上可以看到最后統(tǒng)計信息更新時，采集的RANGE_HI_KEY的最大值為2008-07-31 00:00:00，那么我們插入50條記錄，此時這個數(shù)據(jù)量并不會觸發(fā)統(tǒng)計信息更新。
INSERT INTO Sales.[SalesOrderHeader] ( [RevisionNumber], [OrderDate], [DueDate], [ShipDate], [Status], [OnlineOrderFlag], [PurchaseOrderNumber], [AccountNumber], [CustomerID], [SalesPersonID], [TerritoryID], [BillToAddressID], [ShipToAddressID], [ShipMethodID], [CreditCardID], [CreditCardApprovalCode], [CurrencyRateID], [SubTotal], [TaxAmt], [Freight], [Comment] )VALUES ( 3, '2014-02-02 00:00:00.000', '5/1/2014', '4/1/2014', 5, 0, 'SO43659', 'PO522145787',29825, 279, 5, 985, 985, 5, 21, 'Vi84182', NULL, 250.00,25.00, 10.00, '' );GO 50 -- INSERT 50 rows, representing very recent data, with a current OrderDate value
然后我們開啟SQL跟蹤標志9481,你會發(fā)現(xiàn)下面SQL的預(yù)估行數(shù)為1。因為此時優(yōu)化器采用老的基數(shù)估計。
SELECT [SalesOrderID], [OrderDate] FROM Sales.[SalesOrderHeader]WHERE [OrderDate] = '2014-02-02 00:00:00.000'OPTION (QUERYTRACEON 9481); -- CardinalityEstimationModelVersion 70
取消SQL跟蹤標志時，數(shù)據(jù)庫使用新的基數(shù)估計時，預(yù)估函數(shù)變?yōu)榱?7.9938
DBCC FREEPROCCACHE;GODBCC DROPCLEANBUFFERS;GOSELECT [SalesOrderID], [OrderDate] FROM Sales.[SalesOrderHeader]WHERE [OrderDate] = '2014-02-02 00:00:00.000'
31465 *0.0008896797 ~=27.9937717605 ~= 27.9938 （四舍五入）
白皮書里的例子確實是如此，但是最上面那個例子，不清楚預(yù)估行數(shù)是如何計算的，盡管做了一些推測，但是在其它例子中始終不能驗證。不知是這個白皮書有誤還是SQL Server的基數(shù)估計做了調(diào)整， 還是說基數(shù)估計（CE)的算法遠遠不止這么簡單？我在這個問題上糾結(jié)了兩天，依然沒有搞清楚！在測試、推測過程中，我發(fā)現(xiàn)一個新的問題：當(dāng)表里面新增了數(shù)據(jù)，那么之前的測試列子結(jié)果是否還是一樣呢？答案是不一樣了。如下所示：
SELECT * FROM dbo.TEST_ESTIMATED_ROW WHERE ID = 10;GO
預(yù)估函數(shù)從100變?yōu)榱?03.333， 這個是怎么計算來的呢？ 個人推測是這樣得來的（如下所示）。
SELECT 1550*(100.0/1500) --~= 103.332300
也就是說升序鍵問題（ascending key problem）也會影響預(yù)估函數(shù)。上面都是簡單SQL的預(yù)估行數(shù)（Estimated Number of Rows）的推演、實際情況中，SQL要比這個復(fù)雜得多，那么在復(fù)雜情況下，例如多個過濾謂詞的情況下，基數(shù)估計又是怎樣預(yù)估行數(shù)的呢？由于前面例子構(gòu)造的比較簡單，不適合后面的演示，那么我們就用Optimizing Your Query Plans with the SQL Server 2014 Cardinality Estimator里的例子來簡單演示一下：
USE [AdventureWorks2012];GOSELECT [AddressID], [AddressLine1], [AddressLine2]FROM Person.[Address]WHERE [StateProvinceID] = 9 AND [City] = N'Burbank' AND [PostalCode] = N'91502'OPTION (QUERYTRACEON 9481); -- CardinalityEstimationModelVersion 70GO
如下所示，過濾謂詞[StateProvinceID]、[City]、 [PostalCode]對應(yīng)的統(tǒng)計信息分別為IX_Address_StateProvinceID、_WA_Sys_00000004_164452B1、_WA_Sys_00000006_164452B1。
SELECT [s].[object_id], [s].[name], [s].[auto_created], COL_NAME([s].[object_id], [sc].[column_id]) AS [col_name]FROM sys.[stats] AS sINNER JOIN sys.[stats_columns] AS [sc] ON [s].[stats_id] = [sc].[stats_id] AND [s].[object_id] = [sc].[object_id]WHERE [s].[object_id] = OBJECT_ID('Person.Address');
DBCC SHOW_STATISTICS ('Person.Address', _WA_Sys_00000004_164452B1); -- City
SELECT 196.0/19614 ~= 0.0099928DBCC SHOW_STATISTICS ('Person.Address', IX_Address_StateProvinceID); -- StateProvinceID
SELECT 4564.0/19614 ~= 0.2326909DBCC SHOW_STATISTICS ('Person.Address', _WA_Sys_00000006_164452B1); -- PostalCode
SELECT 194.0/19614 ~= 0.0098908 --記錄
從SQL Server 7 ~ SQL Server 2012， 如果查詢條件中，兩個或多個謂詞使用AND聯(lián)結(jié)，那么各個謂詞的選擇率Si的乘積將作為查詢預(yù)估函數(shù)的選擇率
(S1 * S2 * S3....*Sn)(S1 * S2 * S3....*Sn) *（Rows Sampled） SELECT 0.0098908 * -- PostalCode predicate selectivity 0.0099928 * -- City predicate selectivity 0.2326909 * -- StateProvinceID predicate selectivity 19614; -- Table cardinality
其計算結(jié)果為0.451091024458953138624 ，它低于1行。所以查詢優(yōu)化器使用估計的最小行數(shù) (1)。下面看看SQL Server 2014中新的基數(shù)估計是如何計算預(yù)估行數(shù)的。
SELECT [AddressID], [AddressLine1], [AddressLine2]FROM Person.[Address]WHERE [StateProvinceID] = 9 AND [City] = N'Burbank' AND [PostalCode] = N'91502'GO
那么新的基數(shù)估計（SQL Server 2014）的預(yù)估行數(shù)（Estimated Number of Rows）13.4692是怎么計算來的呢？ 其實它們是選擇率使用下面這樣一個公式，其中p0 < p1 < p2 < p3 < p4
SELECT 0.0098908 * -- PostalCode predicate selectivity SQRT(0.0099928) * -- City predicate selectivity SQRT(SQRT(0.2326909)) * -- StateProvinceID predicate selectivity 19614; -- Table cardinality
計算結(jié)果為13.4690212669225 ~= 13.4692 是否還是有一些差別呢？你使用下面SQL對比，就會發(fā)現(xiàn)，其實原因是小數(shù)點后精確位數(shù)和四舍五入導(dǎo)致的。具體我也不知道計算估計精確位數(shù)。
那么OR Selectivity又是如何計算的，我們先來看看老的基數(shù)估計是是如何計算的，如下例子所示：
USE [AdventureWorks2012];GOSELECT [AddressID], [AddressLine1], [AddressLine2]FROM Person.[Address]WHERE ([StateProvinceID] = 9 OR [City] = N'Burbank' )AND [PostalCode] = N'91502'OPTION (QUERYTRACEON 9481); -- CardinalityEstimationModelVersion 70
0.0098908 -- PostalCode predicate selectivity0.0099928 -- City predicate selectivity0.2326909 -- StateProvinceID predicate selectivity
計算公式：(S1 + S2) 主站蜘蛛池模板： 衡山县| 玉田县| 米脂县| 吉首市| 开封县| 和田县| 东乌珠穆沁旗| 济源市| 榕江县| 黑河市| 铁力市| 壶关县| 岱山县| 台南县| 大荔县| 顺昌县| 洛南县| 天峨县| 正镶白旗| 嵩明县| 宜兰市| 晋州市| 商丘市| 神农架林区| 昌宁县| 宁夏| 喜德县| 长宁区| 宣恩县| 阿克苏市| 昌乐县| 柘城县| 沾化县| 柏乡县| 万年县| 赫章县| 同江市| 准格尔旗| 虞城县| 文登市| 株洲市|