SQLServer中關(guān)于基數(shù)估計(jì)計(jì)算預(yù)估行數(shù)的一些方法探討

關(guān)于SQL Server 2014中的基數(shù)估計(jì)，官方文檔Optimizing Your Query Plans with the SQL Server 2014 Cardinality Estimator里有大量細(xì)節(jié)介紹，但是全部是英文，估計(jì)也沒有幾個(gè)人仔細(xì)閱讀。那么SQL Server 2014中基數(shù)估計(jì)的預(yù)估行數(shù)到底是怎么計(jì)算的呢？ 有哪一些規(guī)律呢？我們下面通過一些例子來初略了解一下，下面測(cè)試案例僅供參考，如有不足或膚淺的地方，敬請(qǐng)指教！

下面實(shí)驗(yàn)測(cè)試的環(huán)境主要為SQL Server 2014 SP2 （Standard Edition (64-bit)） 具體版本號(hào)為12.0.5000.0 ，如有在其它版本測(cè)試，后面會(huì)做具體說明。如下所示，我們先創(chuàng)建一個(gè)測(cè)試表并插入一些測(cè)試數(shù)據(jù)后，方便后面的測(cè)試工作。

IF EXISTS(SELECT 1 FROM sys.objects WHERE type='U' AND name='TEST_ESTIMATED_ROW')
BEGIN
 DROP TABLE TEST_ESTIMATED_ROW;
END
IF 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)
 )
END
GO
DECLARE @Index INT =1;
WHILE @Index <= 100
BEGIN
 INSERT INTO TEST_ESTIMATED_ROW
 VALUES(10, 'id is 10');
 SET @Index+=1;
END
GO
DECLARE @Index INT =1;
WHILE @Index <= 200
BEGIN
 INSERT INTO TEST_ESTIMATED_ROW
 VALUES(20, 'id is 20');
 SET @Index+=1;
END
GO
DECLARE @Index INT =1;
WHILE @Index <= 300
BEGIN
 INSERT INTO TEST_ESTIMATED_ROW
 VALUES(30, 'id is 30');
 SET @Index+=1;
END
GO
DECLARE @Index INT =1;
WHILE @Index <= 400
BEGIN
 INSERT INTO TEST_ESTIMATED_ROW
 VALUES(40, 'id is 40');
 SET @Index+=1;
END
GO
DECLARE @Index INT =1;
WHILE @Index <= 500
BEGIN
 INSERT INTO TEST_ESTIMATED_ROW
 VALUES(50, 'id is 50');
 SET @Index+=1;
END
GO
CREATE INDEX IX_TEST_ESTIMATED_ROW_N1 ON TEST_ESTIMATED_ROW(ID);
GO

我們來看看這個(gè)表的統(tǒng)計(jì)信息以及直方圖內(nèi)容。

DBCC SHOW_STATISTICS ('dbo.TEST_ESTIMATED_ROW','IX_TEST_ESTIMATED_ROW_N1');
GO

SQL Server中有兩種謂詞：過濾謂詞和連接謂詞 。 我們先來看看過濾謂詞的基數(shù)估計(jì)（預(yù)估行數(shù)），測(cè)試過程，如果要保持測(cè)試的公正性或不被其他因素影響，你可以使用下面的DBCC命令來排除干擾，如下例子所示：

DBCC FREEPROCCACHE; --從執(zhí)行計(jì)劃緩沖區(qū)刪除所有緩存的執(zhí)行計(jì)劃
GO
DBCC DROPCLEANBUFFERS; --從緩沖池中刪除所有緩存，清除緩沖區(qū)
GO
SELECT * FROM dbo.TEST_ESTIMATED_ROW WHERE ID = 10;
GO

（注意，執(zhí)行時(shí)請(qǐng)勾選包含實(shí)際執(zhí)行計(jì)劃按鈕）如上所示，預(yù)估行數(shù)（Estimated Number of Rows）為100,跟實(shí)際行數(shù)一致。當(dāng)然你換其他值，例如20， 30， 40 ，50，其預(yù)估行數(shù)（Estimated Number of Rows）跟實(shí)際行數(shù)都是正確的（SQL SERVER 2012中測(cè)試結(jié)果也相同）。那么如果我換一個(gè)不存在的值呢？預(yù)估行數(shù)會(huì)是多少呢？

SELECT * FROM dbo.TEST_ESTIMATED_ROW WHERE ID = 4;
GO

如上所示，預(yù)估行數(shù)（Estimated Number of Rows）為1. 你換其他任何不存在的值，預(yù)估行數(shù)（Estimated Number of Rows）都為1。這個(gè)跟沿用了老的基數(shù)評(píng)估：超出統(tǒng)計(jì)信息范圍，那么老的基數(shù)評(píng)估就認(rèn)為不存在，評(píng)估行數(shù)為1。很顯然，對(duì)于沒有超出統(tǒng)計(jì)信息范疇的，但是確實(shí)不存在的記錄，其預(yù)估行數(shù)（Estimated Number of Rows）也是1，這個(gè)基數(shù)估計(jì)確實(shí)是合理，也是正確的。那么如果我使用變量呢？這個(gè)預(yù)估行數(shù)（Estimated Number of Rows）又會(huì)是什么值呢？ 

DECLARE @SID INT = 11; --換任何值都可以
SELECT * FROM dbo.TEST_ESTIMATED_ROW WHERE ID = @SID;
GO

如上截圖所示，實(shí)際執(zhí)行計(jì)劃的預(yù)估行數(shù)（Estimated Number of Rows）是300， 那么如何計(jì)算來的呢？ 其實(shí)你可以根據(jù)公式來計(jì)算， 如果不相信，你可以構(gòu)造各種案例測(cè)試驗(yàn)證一下就能得到答案了. 

  [Row Sampled ]* [ALL density ] = 1500 * 0.2 = 300 也就是統(tǒng)計(jì)信息中抽樣總行數(shù)*All Density（統(tǒng)計(jì)信息對(duì)象中各列的每個(gè)前綴的密度） 

如果你加上OPTION(RECOMPILE)， 那么預(yù)估行數(shù)（Estimated Number of Rows）又會(huì)變成1 

DECLARE @SID INT = 11; 
SELECT * FROM dbo.TEST_ESTIMATED_ROW WHERE ID = @SID OPTION(RECOMPILE)
GO

如果你賦予@SID值為20，并加上OPTION(RECOMPILE)時(shí)，那么預(yù)估行數(shù)（Estimated Number of Rows）就會(huì)變成EQ_ROWS的值了

DECLARE @SID INT = 20; 
SELECT * FROM dbo.TEST_ESTIMATED_ROW WHERE ID = @SID OPTION(RECOMPILE)
GO

接下來，我們修改一下SQL語句，將查詢條件從等于符號(hào)改為大于符號(hào)，如下所示：

DECLARE @SID INT = 11;
SELECT * FROM dbo.TEST_ESTIMATED_ROW WHERE ID > @SID;
GO

如上所示，預(yù)估行數(shù)（Estimated Number of Rows）變?yōu)榱?50，那么這個(gè)值是怎么計(jì)算得來的呢？

計(jì)算公式是： [Row Sampled ] * 0.3（30%）

1500 *0.3= 450

肯定會(huì)有人問，你怎么知道是 [Row Sampled ] * 0.3 呢？ 不會(huì)是你逆推的吧。 不錯(cuò)，這里是一個(gè)推測(cè)（網(wǎng)上也有不少資料都確認(rèn)是0.3，權(quán)且當(dāng)做計(jì)算公式中的一個(gè)常量），而且也做了不少測(cè)試，確實(shí)就是30%。例如你將@SID賦值為41，預(yù)估行數(shù)（Estimated Number of Rows）依然為450，如果你懷疑是緩存的執(zhí)行計(jì)劃緣故，你可以先清空緩存的執(zhí)行計(jì)劃，結(jié)果依然如此。根據(jù)我的測(cè)試，不管你給@SID賦予任何值，預(yù)估行數(shù)（Estimated Number of Rows）全部為450

DBCC FREEPROCCACHE;
GO
DBCC DROPCLEANBUFFERS;
GO
DECLARE @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）又是如何計(jì)算的呢？

DECLARE @SID INT = 20;
SELECT * FROM dbo.TEST_ESTIMATED_ROW WHERE ID > @SID OPTION(RECOMPILE);
GO

這個(gè)1200 是這樣計(jì)算的，如下所示，大于20的RANGE_HI_KEY有30 ， 40， 50 ，他們對(duì)應(yīng)的EQ_ROWS值相加 300+ 400 + 500 =1200， 不信你可以測(cè)試一下，將@SID賦予30，那么預(yù)估行數(shù)（Estimated Number of Rows）就會(huì)變成900. 

那么我們?cè)傩薷囊幌耂QL查詢語句，例如，我們要做一個(gè)區(qū)間查詢，預(yù)估行數(shù)（Estimated Number of Rows）又會(huì)有什么變化呢？

DBCC FREEPROCCACHE;
GO
DBCC DROPCLEANBUFFERS;
GO
DECLARE @Min_Value INT = 20;
DECLARE @Max_Value INT = 50;
SELECT * FROM dbo.TEST_ESTIMATED_ROW WHERE ID > @Min_Value AND ID < @Max_Value
GO

如上所示，預(yù)估行數(shù)（Estimated Number of Rows）為246.475 這個(gè)值怎么來的呢？其實(shí)它是這樣計(jì)算的:

Selectivity of most selective predicate * Square root of (selectivity of second most selective predicate) * Total number of rows
SELECT 0.3*SQRT(0.3)*1500 --246.475150877325 --0.3是計(jì)算規(guī)則里面的一個(gè)常量

那么如果我在SQL Server 2012中執(zhí)行該SQL語句或者使用查詢跟蹤標(biāo)記9481來關(guān)閉新的基數(shù)評(píng)估，數(shù)據(jù)庫(kù)優(yōu)化器使用老的基數(shù)評(píng)估，你會(huì)發(fā)現(xiàn)預(yù)估行數(shù)（Estimated Number of Rows）為135了。如下所示：

DBCC FREEPROCCACHE;
GO
DBCC DROPCLEANBUFFERS;
GO
DECLARE @Min_Value INT = 20;
DECLARE @Max_Value INT = 50;
SELECT * FROM dbo.TEST_ESTIMATED_ROW WHERE ID > @Min_Value AND ID < @Max_Value
OPTION (QUERYTRACEON 9481);
GO

這里的計(jì)算公式是

((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í)這個(gè)數(shù)據(jù)量是不會(huì)觸發(fā)統(tǒng)計(jì)信息更新的，而此時(shí)ID=55的值超出了直方圖中的RANG_HI_KY的最大值50，也就是說直方圖中沒有統(tǒng)計(jì)這些新插入的數(shù)據(jù)，那這種情形稱作升序鍵問題（ascending key problem）。在更統(tǒng)計(jì)信息新前就對(duì)這些數(shù)據(jù)運(yùn)行查詢，就會(huì)發(fā)生此類問題。

DECLARE @Index INT =1;
WHILE @Index <= 50
BEGIN
 INSERT INTO TEST_ESTIMATED_ROW
 VALUES(55, 'id is 50');
 SET @Index+=1;
END
GO

那么再來看看下面SQL的預(yù)估行數(shù)（Estimated Number of Rows），如下所示：

DBCC FREEPROCCACHE;
GO
DBCC DROPCLEANBUFFERS;
GO
SELECT * FROM dbo.TEST_ESTIMATED_ROW WHERE ID = 55;
GO

那么預(yù)估行數(shù)（Estimated Number of Rows）為39.37 是怎么計(jì)算來的呢？其實(shí)這個(gè)問題就是http://www.cnblogs.com/wy123/p/6770258.html這篇博客里面提出的問題，先前++C++他在群里面討論了一下。

Optimizing Your Query Plans with the SQL Server 2014 Cardinality Estimator里面介紹，這種是基數(shù)估計(jì)的計(jì)算公式為 [All density] * [Rows Sampled] 。但是實(shí)際測(cè)試發(fā)現(xiàn)這個(gè)例子并不是如此，那么我們先來親自測(cè)試一下白皮書文檔里面的例子（注意，數(shù)據(jù)庫(kù)實(shí)例是SQL Server 2014，AdventureWorks2012的兼容級(jí)別為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 s
INNER 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)計(jì)信息為_WA_Sys_00000003_4B7734FF

DBCC SHOW_STATISTICS('Sales.SalesOrderHeader', _WA_Sys_00000003_4B7734FF);

從上可以看到最后統(tǒng)計(jì)信息更新時(shí)，采集的RANGE_HI_KEY的最大值為2008-07-31 00:00:00，那么我們插入50條記錄，此時(shí)這個(gè)數(shù)據(jù)量并不會(huì)觸發(fā)統(tǒng)計(jì)信息更新。

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跟蹤標(biāo)志9481,你會(huì)發(fā)現(xiàn)下面SQL的預(yù)估行數(shù)為1。因?yàn)榇藭r(shí)優(yōu)化器采用老的基數(shù)估計(jì)。 

SELECT [SalesOrderID], [OrderDate] 
FROM Sales.[SalesOrderHeader]
WHERE [OrderDate] = '2014-02-02 00:00:00.000'
OPTION (QUERYTRACEON 9481); -- CardinalityEstimationModelVersion 70

取消SQL跟蹤標(biāo)志時(shí)，數(shù)據(jù)庫(kù)使用新的基數(shù)估計(jì)時(shí)，預(yù)估函數(shù)變?yōu)榱?7.9938

DBCC FREEPROCCACHE;
GO
DBCC DROPCLEANBUFFERS;
GO
SELECT [SalesOrderID], [OrderDate] 
FROM Sales.[SalesOrderHeader]
WHERE [OrderDate] = '2014-02-02 00:00:00.000'

31465 *0.0008896797 ~=27.9937717605 ~= 27.9938 （四舍五入）

白皮書里的例子確實(shí)是如此，但是最上面那個(gè)例子，不清楚預(yù)估行數(shù)是如何計(jì)算的，盡管做了一些推測(cè)，但是在其它例子中始終不能驗(yàn)證。不知是這個(gè)白皮書有誤還是SQL Server的基數(shù)估計(jì)做了調(diào)整， 還是說基數(shù)估計(jì)（CE)的算法遠(yuǎn)遠(yuǎn)不止這么簡(jiǎn)單？我在這個(gè)問題上糾結(jié)了兩天，依然沒有搞清楚！在測(cè)試、推測(cè)過程中，我發(fā)現(xiàn)一個(gè)新的問題：當(dāng)表里面新增了數(shù)據(jù)，那么之前的測(cè)試列子結(jié)果是否還是一樣呢？答案是不一樣了。如下所示：

SELECT * FROM dbo.TEST_ESTIMATED_ROW WHERE ID = 10;
GO

預(yù)估函數(shù)從100變?yōu)榱?03.333， 這個(gè)是怎么計(jì)算來的呢？ 個(gè)人推測(cè)是這樣得來的（如下所示）。

SELECT 1550*(100.0/1500) --~= 103.332300 

也就是說升序鍵問題（ascending key problem）也會(huì)影響預(yù)估函數(shù)。上面都是簡(jiǎn)單SQL的預(yù)估行數(shù)（Estimated Number of Rows）的推演、實(shí)際情況中，SQL要比這個(gè)復(fù)雜得多，那么在復(fù)雜情況下，例如多個(gè)過濾謂詞的情況下，基數(shù)估計(jì)又是怎樣預(yù)估行數(shù)的呢？由于前面例子構(gòu)造的比較簡(jiǎn)單，不適合后面的演示，那么我們就用Optimizing Your Query Plans with the SQL Server 2014 Cardinality Estimator里的例子來簡(jiǎn)單演示一下： 

USE [AdventureWorks2012];
GO
SELECT [AddressID],
 [AddressLine1],
 [AddressLine2]
FROM Person.[Address]
WHERE [StateProvinceID] = 9 AND
 [City] = N'Burbank' AND
 [PostalCode] = N'91502'
OPTION (QUERYTRACEON 9481); -- CardinalityEstimationModelVersion 70
GO

如下所示，過濾謂詞[StateProvinceID]、[City]、 [PostalCode]對(duì)應(yīng)的統(tǒng)計(jì)信息分別為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 s
INNER 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.0099928
DBCC SHOW_STATISTICS ('Person.Address', IX_Address_StateProvinceID); -- StateProvinceID

SELECT 4564.0/19614 ~= 0.2326909
DBCC SHOW_STATISTICS ('Person.Address', _WA_Sys_00000006_164452B1); -- PostalCode

SELECT 194.0/19614 ~= 0.0098908 --記錄

從SQL Server 7 ~ SQL Server 2012， 如果查詢條件中，兩個(gè)或多個(gè)謂詞使用AND聯(lián)結(jié)，那么各個(gè)謂詞的選擇率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

其計(jì)算結(jié)果為0.451091024458953138624 ，它低于1行。所以查詢優(yōu)化器使用估計(jì)的最小行數(shù) (1)。下面看看SQL Server 2014中新的基數(shù)估計(jì)是如何計(jì)算預(yù)估行數(shù)的。

SELECT [AddressID],
 [AddressLine1],
 [AddressLine2]
FROM Person.[Address]
WHERE [StateProvinceID] = 9 AND
 [City] = N'Burbank' AND
 [PostalCode] = N'91502'
GO

那么新的基數(shù)估計(jì)（SQL Server 2014）的預(yù)估行數(shù)（Estimated Number of Rows）13.4692是怎么計(jì)算來的呢？ 其實(shí)它們是選擇率使用下面這樣一個(gè)公式，其中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

計(jì)算結(jié)果為13.4690212669225 ~= 13.4692 是否還是有一些差別呢？你使用下面SQL對(duì)比，就會(huì)發(fā)現(xiàn)，其實(shí)原因是小數(shù)點(diǎn)后精確位數(shù)和四舍五入導(dǎo)致的。具體我也不知道計(jì)算估計(jì)精確位數(shù)。

那么OR Selectivity又是如何計(jì)算的，我們先來看看老的基數(shù)估計(jì)是是如何計(jì)算的，如下例子所示：

USE [AdventureWorks2012];
GO
SELECT [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 selectivity
0.0099928 -- City predicate selectivity
0.2326909 -- StateProvinceID predicate selectivity

計(jì)算公式：(S1 + S2) – (S1 * S2) ，那么(S1 + S2) – (S1 * S2) 計(jì)算的值為

(0.0099928 + 0.2326909) - (0.0099928 * 0.2326909) ~= 0.24035846637448 

然后和AND操作，我們執(zhí)行SQL Server 2014以前的AND的選擇性是這樣計(jì)算的S1 * S2

0.0098908 * ((0.0099928 + 0.2326909) - (0.0099928 * 0.2326909)) ~= 0.002377337519216706784

最后的計(jì)算結(jié)果如下：

0.002377337519216706784 *19614 ~= 46.629098101916486861376 ~= 46.6296 （注意這個(gè)誤差是因?yàn)榫_小數(shù)位數(shù)和四舍五入造成的） 

那么我們?cè)賮砜纯碨QL Server 2014下OR Selectivity的計(jì)算公式

USE [AdventureWorks2012];
GO
SELECT [AddressID],
 [AddressLine1],
 [AddressLine2]
FROM Person.[Address]
WHERE ([StateProvinceID] = 9 OR
 [City] = N'Burbank' )AND
 [PostalCode] = N'91502'

那么這個(gè)預(yù)估行數(shù)（Estimated Number of Rows）是怎么算出來的呢？ Paul White 的博客介紹，是通過下面這樣計(jì)算來的。

0.0098908 -- PostalCode predicate selectivity
0.0099928 -- City predicate selectivity
0.2326909 -- StateProvinceID predicate selectivity 

A OR B = NOT （( NOT A) AND (NOT B)) 就是說A OR B 和 NOT （( NOT A) AND (NOT B)) 是等價(jià)的。 

那么就可以這么推算，最后的預(yù)估行數(shù)（Estimated Number of Rows）計(jì)算結(jié)果為94.3525， 跟結(jié)果94.3515有細(xì)微差別（這個(gè)是因?yàn)楦↑c(diǎn)數(shù)精度和四舍五入造成的）

SELECT 1- (1- 0.2326909)*SQRT(( 1-0.0099928)) ~= 0.236534308898679
SELECT 0.009891 *SQRT(1- (1- 0.2326909)*SQRT(( 1-0.0099928)) )*19614 ~= 94.3525070823501 ~= 94.3515

上面是關(guān)于SQL Server中的基數(shù)估計(jì)（CE)如何計(jì)算預(yù)估行數(shù)的一些初步的探討和認(rèn)識(shí)，糾結(jié)我的問題到目前還沒有弄清楚。雖然有點(diǎn)遺憾，但是在測(cè)試過程，發(fā)現(xiàn)去探究這些規(guī)律是一件非常有意思的事情.

以上所述是小編給大家介紹的SQL Server中關(guān)于基數(shù)估計(jì)計(jì)算預(yù)估行數(shù)的一些方法探討，希望對(duì)大家有所幫助，如果大家有任何疑問請(qǐng)給我留言，小編會(huì)及時(shí)回復(fù)大家的。在此也非常感謝大家對(duì)腳本之家網(wǎng)站的支持！

聲明：本網(wǎng)頁(yè)內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com