web-dev-qa-db-ja.com

統計の更新:インデックススキャンの推定行数が実際と等しくありません。どうして?

フルスキャンで統計を強制的に更新すると、実行計画の見積もりにどのような影響があるかを理解しようとしています。

私は現在、非常に単純なSELECTクエリの実行プランで次の結果を得ています。 enter image description here

ご覧のとおり、5行ずれています。

次に実行します:

UPDATE STATISTICS  Person.Address WITH FULLSCAN
UPDATE STATISTICS  Person.Address [PK_Address_AddressID] WITH FULLSCAN
GO
EXEC sp_recompile 'Person.Address';
GO
SELECT * FROM Person.Address OPTION(RECOMPILE)

ただし、それでも5行ずれています。どうして?

パフォーマンスの問題がない限り、心配する必要はありません。しかし、私は完全な統計更新の実際の影響を理解しようとしています

4
k29

行数は、6桁の情報しか保持していないようです(フロートの仮数と呼ばれているようです)。

次の例では、11,111,111行のテーブルがあります。ただし、推定行は11,111,100としてのみ表示されます。

USE TestDB
GO

DROP TABLE IF EXISTS dbo.stattest
GO
CREATE TABLE dbo.stattest (ID int primary key, junk char(1))

INSERT dbo.stattest
SELECT TOP 11111111 ROW_NUMBER() OVER(ORDER BY 1/0), 'a'
FROM master..spt_values a
CROSS JOIN master..spt_values b
CROSS JOIN master..spt_values c

SELECT COUNT(*)
FROM dbo.stattest

興味深いことに、statsオブジェクトはすべての11,111,111行を表示します。

UPDATE STATISTICS dbo.stattest WITH FULLSCAN
GO
SELECT *
FROM sys.dm_db_stats_properties(OBJECT_ID('dbo.stattest'),1)

TF 2363を追加すると、カーディナリティの推定プロセス中に丸めが発生することがわかります。

SELECT COUNT(*)
FROM dbo.stattest
OPTION(
QUERYTRACEON 3604,
QUERYTRACEON 2363
)

CStCollBaseTable(ID = 1、CARD = 1.11111e + 007 TBL:dbo.stattest)

8
Forrest