一意のインデックススキャン後に集計演算子が使用される理由


15

NULL不可の値に対してフィルター処理された一意のインデックスを持つテーブルがあります。クエリプランでは、distinctの使用があります。これには理由がありますか?

USE tempdb

CREATE TABLE T1( Id INT NOT NULL  IDENTITY PRIMARY KEY ,F1 INT , F2 INT )
go
CREATE UNIQUE NONCLUSTERED INDEX UK_T1 ON T1 (F1,F2) WHERE F1 IS NOT NULL AND F2 IS NOT NULL 
GO
INSERT INTO  T1(f1,F2) VALUES(1,1),(1,2),(2,1)

SELECT DISTINCT   F1,F2 FROM T1 WHERE F1 IS NOT NULL AND F2 IS NOT NULL 
SELECT  F1,F2 FROM T1 WHERE F1 IS NOT NULL AND F2 IS NOT NULL  

クエリプラン: ここに画像の説明を入力してください

回答:


15

これは、既知のSQL Serverクエリオプティマイザーの制限です。Microsoftに報告されていますが、接続項目(使用不可)は修正されませんでした。

この制限には、フィルター付きインデックスのオプティマイザーの制限で説明したものを含む、追加の結果があります。要約を以下に引用します。

この投稿では、フィルター選択されたインデックスに関する2つの重要なオプティマイザーの制限を強調しています。

  • フィルター選択されたインデックスを一致させるには、冗長な結合述語が必要になる場合があります
  • フィルター処理された一意のインデックスは、オプティマイザーに一意情報を提供しません

場合によっては、すべてのクエリに単純に冗長な述語を追加することが実用的かもしれません。別の方法は、インデックスのないビューに目的の暗黙の述語をカプセル化することです。この投稿のハッシュ一致プランは、オプティマイザーがわずかに優れたマージ結合プランを見つけることができるはずですが、デフォルトのプランよりもはるかに優れていました。場合によっては、ビューにインデックスを付けてNOEXPANDヒントを使用する必要がある場合があります(とにかくStandard Editionインスタンスに必要です)。さらに他の状況では、これらのアプローチはどれも適切ではありません。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.