フィルタリングされたインデックスがより強力な機能になる方法

誤解しないでください。フィルター処理されたインデックスが大好きです。これらは、I / Oをはるかに効率的に使用する機会を生み出し、最終的に、適切なANSI準拠の一意の制約を実装できるようにします（複数のNULLが許可されている場合）。しかし、それらは完璧にはほど遠いです。フィルター処理されたインデックスを改善して、そこにあるワークロードの大部分に対してはるかに便利で実用的なものにすることができるいくつかの領域を指摘したいと思いました。

まず、良いニュース

フィルター処理されたインデックスは、以前は高価だったクエリを非常に迅速に処理できるため、使用するスペースが少なくて済みます（したがって、スキャンした場合でもI / Oが削減されます）。

Sales.SalesOrderDetailEnlargedを使用した簡単な例 （Jonathan Kehayias（@SQLPoolBoy）によってこのスクリプトを使用して構築されました）。このテーブルには4.8MM行があり、587MBのデータと363MBのインデックスがあります。 null許容列はCarrierTrackingNumberだけです。 、それではそれで遊んでみましょう。現状では、テーブルには現在、これらの値の約半分（2.4MM）がNULLとして含まれています。フィルター処理されたインデックスの利点を最もよく強調するために、テーブル内の行のごく一部が実際にインデックスに適格であるシナリオをシミュレートするために、これを約240Kに減らします。次のクエリは2.17MM行に影響し、 CarrierTrackingNumberの値がNULLの241,507行を残します ：

UPDATE Sales.SalesOrderDetailEnlarged 
    SET CarrierTrackingNumber = 'x'
      WHERE CarrierTrackingNumber IS NULL
      AND SalesOrderID % 10 <> 3;

ここで、追跡番号がまだ割り当てられていない製品を含む注文を常に確認したいというビジネス要件があるとします（分割されて別々に出荷される注文を考えてみてください）。現在のテーブルで、これらのクエリを実行します（そして、すべての場合にコールドキャッシュを確保するためにDBCCコマンドを追加しました）：

DBCC DROPCLEANBUFFERS;
DBCC FREEPROCCACHE;
 
SELECT COUNT(*)
  FROM Sales.SalesOrderDetailEnlarged 
  WHERE CarrierTrackingNumber IS NULL;
 
SELECT ProductID, SalesOrderID
  FROM Sales.SalesOrderDetailEnlarged
  WHERE CarrierTrackingNumber IS NULL;

これには、クラスター化インデックススキャンが必要であり、次のランタイムメトリックが生成されます（SQL Sentry Plan Explorerでキャプチャされたもの）：

「昔」（SQL Server 2005以降を意味する）では、このインデックスを作成していました（実際、SQL Server 2012でも、これはSQL Serverが推奨するインデックスです）：

CREATE INDEX IX_NotVeryHelpful
ON [Sales].[SalesOrderDetailEnlarged] ([CarrierTrackingNumber])
INCLUDE ([SalesOrderID],[ProductID]);

そのインデックスを設定し、上記のクエリを再度実行すると、次のメトリックが表示されます。両方のクエリで、予想どおりにインデックスシークが使用されます。

次に、そのインデックスを削除して少し異なるインデックスを作成し、 WHEREを追加するだけです。 条項：

CREATE INDEX IX_Filtered_CTNisNULL
ON [Sales].[SalesOrderDetailEnlarged] ([CarrierTrackingNumber])
INCLUDE ([SalesOrderID],[ProductID])
WHERE CarrierTrackingNumber IS NULL;

これらの結果が得られ、両方のクエリでフィルタリングされたインデックスがシークに使用されます。

上記のクエリの実行時間とI/Oの削減と比較して、各インデックスに必要な追加のスペースは次のとおりです。

つまり、ご覧のとおり、フィルター処理されたインデックスは、フィルター処理されていないインデックスとほぼ同じパフォーマンスの向上を実現します（どちらも同じ数の読み取りを使用してデータを取得できるため）が、ストレージははるかに少なくなりますフィルタされたインデックスは、フィルタ述語に一致する行を格納および維持するだけでよいため、コストがかかります。

それでは、テーブルを元の状態に戻しましょう。

UPDATE Sales.SalesOrderDetailEnlarged
  SET CarrierTrackingNumber = NULL
  WHERE CarrierTrackingNumber = 'x';
 
DROP INDEX IX_NotVeryHelpful ON Sales.SalesOrderDetailEnlarged;
DROP INDEX IX_Filtered_CTNisNULL ON Sales.SalesOrderDetailEnlarged;

Tim Chapman（@chapmandew）とMichelle Ufford（@sqlfool）は、独自の方法でフィルター処理されたインデックスのパフォーマンス上の利点を概説する素晴らしい仕事をしました。彼らの投稿もチェックする必要があります：

• Michelle Ufford：フィルター処理されたインデックス：知っておくべきこと
• Tim Chapman：フィルター処理されたインデックスの喜び

また、ANSI準拠の固有の制約（一種）

また、ANSI準拠の固有の制約についても簡単に説明したいと思いました。 SQL Server 2005では、次のような一意の制約を作成します。

CREATE TABLE dbo.Personnel
(
  EmployeeID INT PRIMARY KEY,
  SSN CHAR(9) NULL,
  -- ... other columns ...
  CONSTRAINT UQ_SSN UNIQUE(SSN)
);

（制約の代わりに一意の非クラスター化インデックスを作成することもできます。基本的な実装は基本的に同じです。）

さて、エントリー時にSSNがわかっていれば、これは問題ありません：

INSERT dbo.Personnel(EmployeeID, SSN)
VALUES(1,'111111111'),(2,'111111112');

入国時に知られていないSSNが時折ある場合も問題ありません（ビザ申請者、またはSSNを持っておらず、決してそうしない外国人労働者を考えてみてください）：

INSERT dbo.Personnel(EmployeeID, SSN)
VALUES(3,NULL);

ここまでは順調ですね。しかし、秒があるとどうなりますか 社会保障番号が不明な従業員ですか？

INSERT dbo.Personnel(EmployeeID, SSN)
VALUES(4,NULL);

結果：

ALTER TABLE dbo.Personnel DROP CONSTRAINT UQ_SSN;
GO
 
CREATE UNIQUE INDEX UQ_SSN ON dbo.Personnel(SSN)
  WHERE SSN IS NOT NULL;