web-dev-qa-db-ja.com

SQL Server 2014の「大きなテーブルが小さなテーブルに結合する」カーディナリティ推定の最適化のしきい値は何ですか?

SQL Server 2014 Cardinality Estimator ホワイトペーパーによれば、

ただし、新しいCEは、大きなテーブルと小さなテーブルの間に1対多の結合関連付けがあると想定する、より単純なアルゴリズムを使用します。これは、大きなテーブルの各行が小さなテーブルの1つの行と正確に一致することを前提としています。このアルゴリズムは、より大きな入力の推定サイズを結合カーディナリティとして返します。

ただし、SQL Serverがこの最適化の目的で「大きなテーブル」と「小さなテーブル」を決定する方法については触れていません。

これらの基準はどこかに文書化されていますか?それは単純なしきい値(たとえば、「小さなテーブル」は10,000行未満である必要があります)、パーセンテージ(たとえば、「小さなテーブル」は「大きなテーブル」の行の5%未満でなければなりません)、またはさらに複雑な関数ですか?

また、特定の結合に対してこの最適化の使用を強制するトレースフラグまたはクエリヒントはありますか?

最後に、この最適化には、さらにグーグルで使用できる名前がありますか?

マスター/詳細テーブルの結合でこの「大きなテーブルのカーディナリティを使用する」カーディナリティ推定動作が必要なので、私は尋ねていますが、「小さなテーブル」(マスター)は100万行で、「大きなテーブル」(詳細)です。 2200万行です。したがって、私はこの最適化の詳細を学習して、クエリを調整して強制的に使用できるかどうかを確認しようとしています。

6
Justin Grant

ホワイトペーパーでは、例の「大」を定義していません。「大」および「小」という用語を使用して、新しいCEがレガシーCEと比較して行っている計算を説明します。

参照したセクションは、等価述語と不等価述語が混在する結合述語を示しています。新しいCEは、テーブルの行カウントを調べて、どれが「大きい」かを判別し、それを見積もりに使用します。レガシーCEは行数を調べませんでした。各述語の選択性を増加させるだけでした。

HTH

2
SQLRockstar

ホワイトペーパーには、引き続き読み続けると、次のように記載されています。

従来のカーディナリティ推定では、結合述語間の独立性を前提としています。この結果、過小評価が発生しますが、新しいCEはより大きな子演算子の入力からのカーディナリティを使用して結合の基数を単純に推定するため、過大評価になります。

先に進んでGithubからAdventureWorksDWデータベースをインストールし、問題の2つのテーブルを確認すると、次のことがわかります。

クエリ

SELECT COUNT(*) as Count_FactInternetSales FROM dbo.FactInternetSales AS fis
SELECT COUNT(*) as Count_FactProductInventory FROM dbo.FactProductInventory AS fpi

結果

Count_FactInternetSales
-----------------------
60398

(1 row(s) affected)

Count_FactProductInventory
--------------------------
776286

(1 row(s) affected)

したがって、新しいCEは2つのテーブルを比較し、FactProductInventoryテーブルの行数が776286(ホワイトペーパーの数値)であり、 60398FactInternetSalesテーブル用で、CEには2つの数値の大きい方を使用します。

1Mテーブルと22Mテーブルの場合、新しいCEは大規模な22M行テーブルを使用し、ステートメントによっては、これが大きな過大評価となり、パフォーマンスが最適ではなくなる可能性があります。

新しいCEを再びオフにした方がよい場合があります。しかし私が言ったように:それはあなたの声明に依存します。

1