web-dev-qa-db-ja.com

SQL Serverで多対多の結合を示唆する方法は？

列のペア（両方ints）で結合する3つの「大きな」テーブルがあります。

  • Table1には2億行まで
  • Table2には約150万行あります
  • Table3には約600万行あります

各テーブルには、Key1、Key2にクラスター化インデックスがあり、さらに1つの列があります。 Key1はカーディナリティが低く、非常にゆがんでいます。常にWHERE句で参照されます。 Key2がWHERE句で言及されていません。各結合は多対多です。

問題は、カーディナリティの推定です。各結合の出力見積もりは、largerではなくsmallerを取得します。これにより、実際の結果が数百万に相当する場合、最終的な推定値は数百になります。

CEを手掛かりにしてより良い推定を行う方法はありますか？

SELECT 1
FROM Table1 t1
     JOIN Table2 t2
       ON t1.Key1 = t2.Key1
          AND t1.Key2 = t2.Key2
     JOIN Table3 t3
       ON t1.Key1 = t3.Key1
          AND t1.Key2 = t3.Key2
WHERE t1.Key1 = 1;

私が試したソリューション：

  • Key1、Key2での複数列統計の作成
  • Key1でフィルタリングされた統計のトンを作成します（これはかなり役に立ちますが、データベースにユーザーが作成した何千もの統計が含まれます。）

仮面の実行計画 （悪いマスキングのため申し訳ありません）

私が見ている場合、結果には900万行があります。新しいCEは180行を推定します。従来のCEでは6100行と推定されています。

これは再現可能な例です：

DROP TABLE IF EXISTS #Table1, #Table2, #Table3;
CREATE TABLE #Table1 (Key1 INT NOT NULL, Key2 INT NOT NULL, T1Key3 INT NOT NULL, CONSTRAINT pk_t1 PRIMARY KEY CLUSTERED (Key1, Key2, T1Key3));
CREATE TABLE #Table2 (Key1 INT NOT NULL, Key2 INT NOT NULL, T2Key3 INT NOT NULL, CONSTRAINT pk_t2 PRIMARY KEY CLUSTERED (Key1, Key2, T2Key3));
CREATE TABLE #Table3 (Key1 INT NOT NULL, Key2 INT NOT NULL, T3Key3 INT NOT NULL, CONSTRAINT pk_t3 PRIMARY KEY CLUSTERED (Key1, Key2, T3Key3));

-- Table1 
WITH Numbers
     AS (SELECT TOP (1000000) Number = ROW_NUMBER() OVER(ORDER BY t1.number)
         FROM master..spt_values t1
              CROSS JOIN master..spt_values t2),
     DataSize (Key1, NumberOfRows)
     AS (SELECT 1, 2000 UNION
         SELECT 2, 10000 UNION
         SELECT 3, 25000 UNION
         SELECT 4, 50000 UNION
         SELECT 5, 200000)
INSERT INTO #Table1
SELECT Key1
     , Key2 = ROW_NUMBER() OVER (PARTITION BY Key1, T1Key3 ORDER BY Number)
     , T1Key3
FROM DataSize
     CROSS APPLY (SELECT TOP(NumberOfRows) 
                         Number
                       , T1Key3 = Number%(Key1*Key1) + 1 
                  FROM Numbers
                  ORDER BY Number) size;

-- Table2 (same Key1, Key2 values; smaller number of distinct third Key)
WITH Numbers
     AS (SELECT TOP (1000000) Number = ROW_NUMBER() OVER(ORDER BY t1.number)
         FROM master..spt_values t1
              CROSS JOIN master..spt_values t2)
INSERT INTO #Table2
SELECT DISTINCT 
       Key1
     , Key2
     , T2Key3
FROM #Table1
     CROSS APPLY (SELECT TOP (Key1*10) 
                         T2Key3 = Number
                  FROM Numbers
                  ORDER BY Number) size;

-- Table2 (same Key1, Key2 values; smallest number of distinct third Key)
WITH Numbers
     AS (SELECT TOP (1000000) Number = ROW_NUMBER() OVER(ORDER BY t1.number)
         FROM master..spt_values t1
              CROSS JOIN master..spt_values t2)
INSERT INTO #Table3
SELECT DISTINCT 
       Key1
     , Key2
     , T3Key3
FROM #Table1
     CROSS APPLY (SELECT TOP (Key1) 
                         T3Key3 = Number
                  FROM Numbers
                  ORDER BY Number) size;


DROP TABLE IF EXISTS #a;
SELECT col = 1 
INTO #a
FROM #Table1 t1
     JOIN #Table2 t2
       ON t1.Key1 = t2.Key1
          AND t1.Key2 = t2.Key2
WHERE t1.Key1 = 1;

DROP TABLE IF EXISTS #b;
SELECT col = 1 
INTO #b
FROM #Table1 t1
     JOIN #Table2 t2
       ON t1.Key1 = t2.Key1
          AND t1.Key2 = t2.Key2
     JOIN #Table3 t3
       ON t1.Key1 = t3.Key1
          AND t1.Key2 = t3.Key2
WHERE t1.Key1 = 1;
sql-serverjoinsql-server-2016many-to-manycardinality-estimates
9
Steven Hibble

明確にするために、オプティマイザはすでに多対多の結合であることを知っています。マージ結合を強制して推定プランを見ると、結合が多対多であるかどうかを示す結合演算子のプロパティを確認できます。ここで解決する必要のある問題は、カーディナリティの見積もりを増やすことです。おそらく、省略したクエリの部分に対して、より効率的なクエリプランが得られるでしょう。

私が最初に試みることは、_Object3_および_Object5_からの結合の結果を一時テーブルに入れることです。あなたが投稿した計画の場合、それは51393行の単一の列であるため、tempdb内のスペースをほとんど占有しません。一時テーブルで完全な統計を収集できますが、それだけで十分な正確な最終カーディナリティの見積もりを取得できます。 _Object1_の完全な統計を収集することも役立つ場合があります。カーディナリティーの見積もりは、プランから右から左にトラバースするにつれて悪化することがよくあります。

それが機能しない場合、データベースまたはサーバーレベルで有効にしていない場合は、_ENABLE_QUERY_OPTIMIZER_HOTFIXES_クエリヒントを試すことができます。 Microsoftは、SQL Server 2016の計画に影響するパフォーマンス修正をその設定の背後にロックしています。それらのいくつかはカーディナリティの見積もりに関連しているので、おそらくあなたは幸運になるでしょうし、修正の1つがクエリに役立つでしょう。また、_FORCE_LEGACY_CARDINALITY_ESTIMATION_クエリヒントを使用して、従来のカーディナリティエスティメータを使用することもできます。レガシーCEを使用すると、特定のデータセットでより適切な推定が得られる場合があります。

最後の手段として、Adam MachanicのMANY()関数を使用して、任意の係数で基数の見積もりを手動で増やすことができます。私はそれについて別の answer で話しますが、リンクが切れているようです。興味があれば、掘り下げてみることができます。

5
Joe Obbish

SQL Server統計には、統計オブジェクトの先頭列のヒストグラムのみが含まれます。したがって、_Key2_の値のヒストグラムを提供するフィルターされた統計を作成できますが、_Key1 = 1_を含む行の間のみです。各テーブルでこれらのフィルター処理された統計を作成すると、推定が修正され、テストクエリに期待される動作が発生します。新しい結合はそれぞれ、最終的な基数の推定に影響しません（SQL 2016 SP1とSQL 2017の両方で確認されています）。

_-- Note: Add "WITH FULLSCAN" to each if you want a perfect 20,000 row estimate
CREATE STATISTICS st_#Table1 ON #Table1 (Key2) WHERE Key1 = 1
CREATE STATISTICS st_#Table2 ON #Table2 (Key2) WHERE Key1 = 1
CREATE STATISTICS st_#Table3 ON #Table3 (Key2) WHERE Key1 = 1
_

これらのフィルタリングされた統計がない場合、SQL Serverは、よりヒューリスティックベースのアプローチを使用して、結合のカーディナリティを推定します。次のホワイトペーパーには、SQL Serverが使用するヒューリスティックのいくつかの優れた高レベルの説明が含まれています： SQL Server 2014 Cardinality Estimatorによるクエリプランの最適化 。

たとえば、クエリにUSE HINT('ASSUME_JOIN_PREDICATE_DEPENDS_ON_FILTERS')ヒントを追加すると、結合の包含ヒューリスティックが変更され、_Key1_述語と_Key2_結合述語の間に（独立ではなく）相関があると想定されます。クエリに役立つ場合があります。最後のテストクエリの場合、このヒントは、カーディナリティの見積もりを_1,175_から_7,551_に増やしますが、フィルターされた統計で生成された正しい_20,000_行の見積もりにはまだかなり恥ずかしいです。

同様の状況で使用したもう1つのアプローチは、データの関連サブセットを#tempテーブルに抽出することです。特に、SQL Serverの新しいバージョン ＃tempテーブルをディスクに熱心に書き込む必要がなくなった のおかげで、このアプローチで良い結果が得られました。多対多結合の説明は、ケースの個々の#tempテーブルが比較的小さい（または少なくとも最終結果セットよりも小さい）ことを意味するため、このアプローチは試す価値があります。

_DROP TABLE IF EXISTS #Table1_extract, #Table2_extract, #Table3_extract, #c
-- Extract only the subset of rows that match the filter predicate
-- (Or better yet, extract only the subset of columns you need!)
SELECT * INTO #Table1_extract FROM #Table1 WHERE Key1 = 1
SELECT * INTO #Table2_extract FROM #Table2 WHERE Key1 = 1
SELECT * INTO #Table3_extract FROM #Table3 WHERE Key1 = 1
-- Now perform the join on those extracts, removing the filter predicate
SELECT col = 1
INTO #c 
FROM #Table1_extract t1
JOIN #Table2_extract t2
    ON t1.Key2 = t2.Key2
JOIN #Table3_extract t3
    ON t1.Key2 = t3.Key2
_
2
Geoff Patterson