答え。

インデックス付きビュー (Indexed View、インデックス付き物理ビュー) は、クラスタ化された一意のインデックスが作成されたビュー (VIEW) です。これにより、クエリの結果を物理的にディスクに保存し、インデックスを使用してアクセスを高速化することができます。

利点:

• 集計データや頻繁に使用されるデータの迅速な取得。
• リアルタイム計算の負荷を軽減。

制限:

• すべてのタイプのクエリはサポートされていません (たとえば、TEXT、NTEXT、IMAGE データタイプや、一部の関数は使用できません)。
• 基本テーブルの変更に伴うインデックスの維持に追加のコストがかかります。
• 宣言時に厳密なルールを遵守する必要があります。

コード例

CREATE VIEW dbo.SalesSummary WITH SCHEMABINDING AS
   SELECT SalesPersonID, COUNT_BIG(*) AS SalesCount, SUM(TotalDue) AS TotalDue
   FROM dbo.Sales
   GROUP BY SalesPersonID;
GO
CREATE UNIQUE CLUSTERED INDEX idx_SalesSummary 
   ON dbo.SalesSummary (SalesPersonID);

一筋縄ではいかない質問。

Q: すべてのビューはインデックス (クラスタ化) を作成できますか？

A: いいえ、インデックスを作成できるのは、制約を完全に満たすビューのみです (たとえば、外部参照がないこと、集計関数が整合していることなど)。そうでない場合、インデックス作成のクエリはエラーを返します。

テーマの微妙な点を知らなかったことによる実際のエラーの例。

---

ストーリー

銀行システムの実際のプロジェクトで、集計レポートの取得を加速する必要がありました。テーブルの更新負荷を分析せずにインデックス付きビューを作成しました。大量挿入操作により、主要なテーブルのパフォーマンスが大幅に低下しました。

---

ストーリー

専門家は、外部テーブルへのJOINを指定したVIEWをインデックス化できると誤って考えました。インデックス作成クエリは"Cannot create index on view with non-deterministic functions"というエラーで終了しました。プロジェクトアーキテクチャを修正するのに一日を費やしました。

---

ストーリー

大規模なeコマースプロジェクトで、基本テーブル "Products" のデータ更新がブロッキングの原因となりました。原因は、大量のインデックス付きビューがあり、集計によって数百万行が影響を受ける場合のトランザクション管理が不適切だったことです。