問題タブ [indexed-view]

のインデックス付きビューを作成し、View1トリガーTable1のTable2代わりにトリガーTable1を使用しView1ます。View1トリガーの代わりにこのビューを使用した場合とトリガー後に使用した場合、データは変更されないようです。View1ただし、トリガー後にこのビューを使用する場合は、新しいデータで使用したいと思います。どうすればいいですか。with Noexpandインデックス付きビューを使用する場合はヒントを使用することに注意してください（インデックス付きビューがないなど、このインデックス付きビューを実際に使用しない場合）with noexpand。SQL Server 2008 R2

インデックス付きビューのトランザクション レプリケーションを行っています。NOEXPAND ヒントを使用してインデックス付きビューを参照するスキーマ バインド ビューをレプリケートする他のビューがあります。インデックス付きビューに対して sp_addarticle を呼び出した後、NOEXPANDing ビューに対して sp_addarticle を呼び出しても、次のエラーが発生します。

SQL Server は、インデックス付きビューにインデックスを作成する前に、ターゲット サーバーで NOEXPANDing ビューを作成しようとするためです。

NOEXPANDing ビューを開始する前に、SQL Server にインデックス付きビュー インデックスのレプリケートを強制的に終了させる方法はありますか?

数年で数百万行に成長するテーブルがあります。Webアプリケーションの一部として、ユーザーが特定のページにアクセスするたびに、このテーブルのサブセットのカウントをクエリする必要があります。建築の帽子をかぶった人は、パフォーマンスに懸念があると言っています。それらが正しいと仮定すると、インデックス付きビューを追加することでこの問題に対処できますか？

私が速くなりたいSQL：

また

テーブル：

意見：

索引：

複雑な検索クエリのパフォーマンスを最適化するという考えについて質問があります。これは状況です：

検索するフィールドを含むベース テーブル:

結合するテーブルと検索するフィールド:

私が持っていたアイデアは、次のようなインデックス付きビューを作成することでした:

(ServerID のクラスター化インデックス、Term の非クラスター化)

これは可能なすべてのデータの和集合です:

検索したいときは、これを計画していました：

いいアイデアか悪いアイデアか？

SSAS キューブのデータ ソース ビューとして使用するインデックス付きビューを設定しました。インデックス付きビューは次のようになります。

さて、select * from vw_indexed1おそらく基になるテーブルのインデックスを拡張しようとしているために、時間がかかるのでselect * from vw_indexed1 with (noexpand)、クラスター化されたインデックスを持つテーブルで直接選択するのと同じように実行する を使用します。

私の質問は次のとおりです。このビューを SSAS プロジェクトの DSV として使用する場合、基になるインデックスを毎回使用しようとしますか? vw_indexed1もしそうなら、どうすればそれを独自のインデックスを持つテーブルと見なすことができますか?

何年も前に私がすぐにまとめたレポートが数百万ドルを集める唯一の手段であり、それが正しいかどうかを確認するために何も行われていないことがわかりました.

パフォーマンス上の理由から、レポートではインデックス付きビューが頻繁に使用されます。私はインデックス付きビューを頻繁に使用してきましたが、これほど重要なことには使用しない傾向があるため、これは私にとって懸念事項です。

インデックス付きビューが更新に失敗したり、テーブル内のデータとは異なる情報を返す可能性はありますか? これはどれほど現実的なリスクなのでしょうか? エラーをチェックするために定期的に実行できる優れた SQL スクリプトはありますか?

パフォーマンスへの影響を最小限に抑えながら、複数のインデックス付きビューをプライマリ ファイル グループから別のファイル グループに移動したいと考えています。どうすればこれを達成できますか?

私はこのデッドロックで髪を引っ張ってきました:

【拡大】

IX_OrderAmounts は、Amount テーブルで集計を行うインデックス付きビューです。左側のトランザクション (反復可能な読み取り - コミットされた読み取りでも同じことが起こります) は、Amount テーブルに 1 つの行のみを挿入します。右側のトランザクション (コミットされた読み取り) は、Amount テーブルからいくつかの行 (2 ～ 3 行) を更新します (すべて 1 つの UPDATE ステートメントで)。

ここで、行を挿入するだけでよい左側のトランザクションが、2 番目の更新ロックを取得する必要がある理由がわかりません。

デッドロックは、直接更新しないインデックス付きビューにあるため、SQL ヒントを実際に使用することはできません (または、少なくとも方法がわかりません)。

このデッドロックを解決するにはどうすればよいですか?

多くのテーブルで結合を実行するクエリがあり、パフォーマンスが低下しています。

パフォーマンスを向上させるために、インデックス付きビューを作成しました。日付フィルターを使用したビューでのクエリのパフォーマンスが大幅に向上しました。ただし、私の懸念は、インデックスのストレージについてです。私が読んだことから、一意のクラスター化インデックスは SQL Server に格納されています。ビュー内の結合の一部として生じるデータ全体を個別に保存するということですか? その場合、結合の一部であるテーブルのすべての列をビューに含めた場合、サーバーのディスク容量は、インデックス付きビューを使用しないディスク容量の約 2 倍になりますか? また、基になるテーブルにデータを入力するたびに、データがインデックス付きビューに複製されますか?

ビューにクラスター化インデックスまたは非クラスター化インデックスを作成できます。SQL SERVER によると、複数の非クラスター化インデックス (最大 249) を作成できますが、テーブルまたはビューにはクラスター化インデックスが 1 つしか存在しません。なぜなら、レコードは物理的に保存されている場所でソートされており、複数のソート順を持つことはできないからです。ビューはデータベースに物理的に保存されていないので、私の質問です。次に、ビューにクラスター化インデックスを作成し、ベース テーブルに既にクラスター化インデックスが存在する場合はどうでしょう。ビューにクラスター化されたインデックスをどのように実装しましたか? クラスター化インデックスの仕組みとビューでの有用性は?