高選択性フィールドと低選択性フィールドを持つ複合インデックス順のフィールド順

30億行を超えるSQL Serverテーブルがあります。クエリの1つに非常に長い時間がかかるため、最適化を検討しています。クエリは次のようになります。

SELECT [Enroll_Date]
      ,Count(*) AS [Record #]
      ,Count(Distinct UserID) AS [User #]
  FROM UserTable
  GROUP BY [Enroll_Date]

[Enroll_Date]は選択可能な値が50未満の選択性の低い列ですが、UserID列は2億を超える個別の値を持つ選択性の高い列です。私の研究に基づいて、私はこれらの2つの列に非クラスター化複合インデックスを作成する必要があると考えています。理論的には、高選択性の列が最初の列である必要があります。しかし、私の場合、group by句で低選択性カラムを使用しているため、うまくいくかどうかはわかりません。

このテーブルにはクラスター化インデックスがありません。

@AaronBertrandのソリューションの代替手段として（インデックス付きビューを作成できない場合、または作成したくない場合）、にインデックスを作成することをお勧めします(Enroll_Date, UserID)。このタイプの質問がテーブルで非常に一般的である場合、これはおそらくクラスター化インデックスであるべきです。

一般に、選択性の高いインデックスを一般的な「ベストプラクティス」としてお勧めするのではなく、どのインデックスがクエリに最高のパフォーマンスをもたらすかを調べます。

インデックスをオンに(Enroll_Date, UserID)すると、ストリーム集約を使用した高度に最適化された非ブロッククエリプランがクエリに提供されます。

このコンテキストでの「非ブロッキング」とは、クエリが大量のデータをバッファリングする必要がないことを意味します（たとえば、並べ替えやハッシュ集計のように）、（a）すぐに行を返し始め、（ b）作業メモリを実質的に消費しない。

アーロンズの答えは素晴らしい解決策です。あなたがそのアプローチをとりたくないと仮定して、質問に答えます。

通常、投稿したクエリは、最初にをグループ化し(Enroll_Date, UserID)、次にをグループ化することによって実行され(Enroll_Date)ます。この最適化はSQL Server 2012の新機能COUNT DISTINCTです。単一のの場合に有効になります。

特定の順序でのこれら2つの列のインデックスは(Enroll_Date, UserID)、インデックススキャンを2つの連続するストリーム集約に集める効率的な計画を取得するのに十分です。反対の順序では、その計画は有効になりません。

したがって、順序を使用し(Enroll_Date, UserID)ます。ここには選択の余地はありません。

インデックス付きビューの理想的なシナリオのように聞こえます。これにより、クエリ時間ではなく書き込み時間に計算と集計の料金を支払うことができます。

CREATE VIEW dbo.MyIndexedView
WITH SCHEMABINDING
AS 
  SELECT Enroll_Date, UserID, RawCount = COUNT_BIG(*)
  FROM dbo.UserTable
  GROUP BY Enroll_Date, UserID;
GO

CREATE UNIQUE CLUSTERED INDEX CIX_miv ON dbo.MyIndexedView(Enroll_Date, UserID);

これを作成するには時間がかかります。もちろん、ベーステーブルのインデックスと同じように、すべてのDML操作全体でメンテナンスが必要になります。

これで、このビューに対するクエリは非常によく似たものになります。ビューの各行は個別のユーザー/日付の組み合わせを表すため、ベーステーブルの行の総数は1であるCOUNT（*）で計算できます。すでに部分的に集計されていますが、日付ごとのSUMを使用してそれらを追加するだけです。

SELECT Enroll_Date, 
  [Record #] = SUM(RawCount),
  [User #] = COUNT(*)
FROM dbo.MyIndexedView WITH (NOEXPAND)
GROUP BY Enroll_Date; 

これとthisを思い出した後、NOEXPANDヒントを追加しました。

このクエリが現在のクエリよりも高速であることは間違いありません（ただし、その程度ではありません）。ただし、日付ごとに正確に1人のユーザーがいるというまれなケース（この場合、同じ量のデータには読み取り）と私たちが知っている列は、ベーステーブルのインデックス内の唯一の列です。読み取り時のパフォーマンスの向上が、ワークロードの書き込み部分に影響を与える余分な作業に見合うかどうかは、私たちには言えません-トレードオフを測定するためにテストする必要があります（インデックスは無料です）。

また、特定の明確に定義された範囲（たとえば、現在の四半期または年初から現在まで）に対してEnroll_Dateに対して同じ共通のWHERE句を頻繁に使用する場合は、I / Oをさらに削減する一致するフィルター処理されたインデックスを追加できます（ただし、常にトレード・オフ）。

また、クラスター化インデックスをベーステーブルに配置することも検討してください。これは、ヒープの恩恵を受ける非常にまれなユースケースの1つではないようです。