非常に複雑な選択クエリからビューを作成しようとしていますが、サブクエリといくつかの集計関数を使用する必要があるため、クラスター化インデックスを配置できません。
クラスター化されたインデックスを取得する必要があります。そうしないと、ビューを使用するクエリに永遠に時間がかかります。どうやらSQLサーバーは、ばかげた量の基準を満たした場合にのみ結果セットを保存します。
ビューのベース テーブルは読み取り専用で、1 日に 1 回の一括インポートによってのみ更新されます。結果をキャッシュできない理由がわかりません。
SQLサーバーにビューの結果をキャッシュさせて、後でクエリできるようにする方法を知っている人はいますか?? あちこちで雪だるま式に変化するような別のテーブル cos を作成したくありません。
前もって感謝します。
私はあなたが探している答えは次のとおりだと思います：これを行うためにビューを使用しないでください。SQLクエリから返されたフィールドに対応するフィールドを持つテーブルを使用します。クエリを自動化して、このテーブルにデータを入力します
構築しているものはデータウェアハウスのように聞こえるので、システムにデータが入ったらデータを操作するのが最善の選択肢です。非正規化された（または変更している）新しいテーブルを作成し、それらにインデックスを付けて、すばやくクエリを実行できるようにすることができます。
その後、必要に応じて、これらのテーブルの上にビューを作成できます。
簡単に言うと、あなたが言及した理由により、クラスター化されたインデックスを作成することはできません。
複雑なクエリの結果をキャッシュする方法を尋ねるとき、SQL Serverが提供する（そして問題を解決する）他のオブジェクトはテーブルだけです。
自動化が問題になる場合は、ビューの作成を検討する必要がありますが、一括挿入の直後に（ビューから選択して）テーブルに切り捨て/挿入できるように、テーブルに挿入する方法としてのみ使用してください。
SSIS（SQL Server Integration Services）を使用する場合、これを追加するのは比較的簡単です。
私の知る限り、実行計画をコンパイルするとき、SQL Serverは基本的にビューの定義をコピーしてコンパイル中のクエリに貼り付けます-基になるテーブルにインデックスを追加できる限り、良好なパフォーマンスを得ることができるはずですクエリから。
インデックス付きビュー内で集計を使用する場合は、COUNT() の代わりに COUNT_BIG() を使用する必要があります。そうしないと、ビューが作成されません。
また、Enterprise Edition を使用していない場合は、NOEXPAND ヒントを提供する必要があります。そうしないと、オプティマイザーはビューを使用しません。
SELECT *
FROM YourView WITH(NOEXPAND)
WHERE ....
ビューは必要ないかもしれませんが、テーブルに正しいインデックスがないだけです。テーブルの DDL (インデックスと制約を含む) を投稿できますか?
同じ問題が発生し、サブクエリをクラスター化インデックスビュー自体に配置することになりました。