1

Table1_IDこのようなT-SQLを使用して、インデックス付きビュー（クラスター化された一意のインデックス）ビューを作成しました。

Select Table1_ID, Count_BIG(*) as Table2TotalCount from Table2 inner join
Table1 inner join... where Table2_DeletedMark=0 AND ... Group BY Table1_ID

また、ビューを作成した後、Table1_ID列にクラスター化された一意のインデックスを設定しました。
したがって、Viewは2つの列で構成されます。

Table1_ID
Table2TotalCount

Viewを作成するためのT-Sqlは、Table2のgroup byと数百万の行のために、重いものです。

しかし、私が次のようなビューにクエリを実行すると

Select Total2TotalCount from MyView where Table1_ID = k

-サーバーのオーバーヘッドなしで高速に実行されます。

また、t-sqlでは、Table2列のwhere句で多くの条件を表示します。そして、Table2_DeletedMarkを1に変更して、クエリを実行した場合

Select Total2TotalCount from MyView where Table1_ID = k

もう一度-正しい結果が得られます。（Table2TotalCount1減少）。

したがって、質問は次のとおり
です。1.インデックス付きビューを使用したときにクエリの実行時間が大幅に短縮されたのはなぜですか（ビューを使用しない場合と比較して（DBCC DROPCLEANBUFFERS()VIEWにクエリを実行する前に実行した場合でも））
2。変更後

Table2_DeletedMark

ビューはすぐに再計算され、正しい結果が得られますが、背後にあるプロセスは何ですか？生成するt-sqlビューに含まれる10以上の列の値を変更するたびに、生成されたビューによってsqlがt-sqlを実行することは想像できません。これは、重すぎるためです。
変更する列の値に応じて、値を再計算するための単純なクエリを実行するだけで十分であることを理解しています。
しかし、SQLはそれをどのように理解しますか？

4

2 に答える 2

2

インデックス付きビューは具体化されます。たとえば、ビューに含まれる（依存するテーブルからの）行は物理的にディスクに格納されます。これは、基になるテーブルが変更されるたびに常に最新の状態に保たれる「システム計算」テーブルのようなものです。これは、クラスター化インデックスを追加することによって行われます。SQLServerテーブル（またはビュー）上のクラスター化インデックスのリーフページは、実際にはデータページです。

インデックス付きビューの列は、非クラスター化インデックスを使用してインデックスを作成することもできるため、クエリのパフォーマンスをさらに向上させることができます。欠点は次のとおりです。行が保存されるため、ディスク容量が必要です（そして、明らかに一部のデータが複製されます）。

一方、通常のビューは、そのビューから選択したものに基づいて結果を計算するために実行されるSQLのフラグメントにすぎません。そのビューの物理的な表現はなく、通常のビュー用に保存された行もありません。必要に応じて、ベーステーブルからそれらを結合する必要があります。

于 2010-12-10T11:29:15.050 に答える
0

インデックス付きビューで何が許可され、ベーステーブルで何が許可されるかについて、なぜこれほど多くの奇妙なルールがあると思いますか？これは、SQLエンジンが「この行に触れている場合、このビューの結果に影響を与える可能性があることをすぐに知ることができるようにするためです。この行はビューの基準に適合しなくなりましたが、COUNT_BIG（*）を使用することを主張しました。だから私はその値を1つ減らすことができます」

于 2010-12-10T11:57:54.157 に答える