多くのテーブルで結合を実行するクエリがあり、パフォーマンスが低下しています。
パフォーマンスを向上させるために、インデックス付きビューを作成しました。日付フィルターを使用したビューでのクエリのパフォーマンスが大幅に向上しました。ただし、私の懸念は、インデックスのストレージについてです。私が読んだことから、一意のクラスター化インデックスは SQL Server に格納されています。ビュー内の結合の一部として生じるデータ全体を個別に保存するということですか? その場合、結合の一部であるテーブルのすべての列をビューに含めた場合、サーバーのディスク容量は、インデックス付きビューを使用しないディスク容量の約 2 倍になりますか? また、基になるテーブルにデータを入力するたびに、データがインデックス付きビューに複製されますか?
That is correct. An indexed view is basically an additional table that contains a copy of all the data in a sorted way. That's what makes it so fast, but as everything in SQL Server land, it comes at a price - in this case the additional storage required and the additional time required to keep all the copies of the data in sync.
同じことがテーブルの通常のインデックスにも当てはまります。これは、インデックス キーのコピーでもあり (元の行の場所に関する情報も含まれます)、追加のストレージと更新中の追加の時間を維持する必要があります。
テーブルまたはビューにインデックスを追加することが理にかなっているのかどうかを判断するには、システム全体を見て、1 つのクエリのパフォーマンスの向上が他のクエリのパフォーマンスの低下に見合うかどうかを確認する必要があります。
あなたの場合、基になるテーブルの追加のインデックスがクエリに役立つかどうかも（最初に）確認する必要があります。
はい、そうです。インデックス付きビューは、ビュー内のすべてのデータをソース テーブルとは別に永続化します。列と結合によっては、データが複製され、実際にはソース テーブルよりも何倍も大きくなる可能性があります。
Pretty much, yeah. You've made a trade-off where you get better performance in return for some additional effort by the engine, plus the additional storage needed to persist it.